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Abstract 

The  purpose  of  this  research  was  to  develop  a  general,  statistical  model  of  order- 
to-delivery  times  for  commercial  satellite  imagery.  The  research  looked  at  the  current 
four  satellites  providers  with  3 -meter  or  better  imagers  in  the  context  of  a  generalized 
model  of  commercial  imaging  satellite  operations.  Existing  methods  use  orbit  analysis 
tools  to  determine  imaging  time  of  a  specified  target  based  on  defined  satellite  position 
and  times  but  can  only  develop  shortest  and  longest  times  to  an  imaging  opportunity.  To 
address  the  general  question  of  the  time  to  deliver  an  image  for  non-specific  targets,  this 
research  develops  a  process  model  using  Arena  simulation  software  and  random  targets 
within  large  defined  regions.  Analysis  of  delivery  times  conducted  on  the  output  reveals 
dependencies  on  collective  satellite  coverage,  prediction  of  weather  over  the  target  area, 
number  of  collection  requests  in  the  system  and  the  computer  and  communications 
resources  of  the  satellite  operator. 
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MODELING  AND  SIMULATION  OL  THE  COMMERCIAL  SATELLITE  IMAGERY 


PROCESSES 


I.  Introduction 


Overview 

Modem  commercial  satellite  imaging  has  moved  the  satellite  remote  sensing 
industry  into  new  areas  of  application  such  as  insurance  assessment,  community 
planning,  disaster  relief  and,  most  significantly  for  this  research,  intelligence.  With 
four  commercial  entities  with  advertised  resolutions  better  than  3  meters, 
governments  or  non-govemmental  actors  can  purchase  images  with  resolutions  equal 
to,  or  better  than,  the  military  reconnaissance  satellites  of  world  powers.  But  there 
are  two  determinants  of  intelligence  value  to  the  user:  the  first  is  the  clarity  of  objects 
in  the  image,  driven  by  the  resolution  offered  by  the  satellite  payload;  the  second  is 
the  timeliness  of  the  image,  driven  by  a  number  of  considerations  and  explored  in  this 
research. 

The  four  high  resolution  satellites  are  Quickbird  2,  Ikonos  2,  Orbview  3,  and 
EROS  Al.  Quickbird  2,  owned  and  operated  by  DigitalGlobe  of  Longmont, 
Colorado,  is  capable  of  60  cm  panchromatic  imagery.  (A  note  on  resolution; 
throughout  this  paper,  resolution  is  used  in  the  sense  of  ground  sample  distance,  or 
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equivalently,  meters  per  pixel.)  The  threat  potential  of  imagery  of  this  resolution  is  so 
significant  that  government  licenses  authorizing  operations  of  Quickbird  2 
specifically  prohibit  release  of  high-resolution  images  less  than  24  hours  after  it  is 
taken  (Quickbird  Product  Release).  While  Ikonos  2  and  Orbview  3  are  both  capable 
of  1 -meter  resolution,  versus  the  0.6-meters  of  Quickbird  2,  they  both  operate  under 
other  conditions,  such  as  shutter  control,  imposed  by  the  U.S.  (Licensing,  2005). 
However,  EROS  A1  and  other  imagers  on-orbit  or  planned  will  not  be  operated  by 
U.S.  entities  and  so  will  not  be  subject  to  U.S.  imposed  limitations. 

Future  plans  for  the  commercial  operators  include  full-fledged  constellations  of 
two,  three,  or  more  imagers.  The  Indian  Space  Research  Organization  (ISRO) 
operated  IRS  satellite  project  includes  several  satellites  with  1  to  5.8-meter  capability 
(Appendix  B)  while  the  Israel  based  ImageSat  International  has  similar  plans  for  8 
satellites,  all  with  1 -meter  resolution  (Bar-Lev,  2001).  The  France  based  SPOT 
Image  satellites,  with  two  operational  satellites  on  orbit  (the  4th  and  5th  of  the  series), 
plan  to  maintain  that  number  while  upgrading  resolutions  and  are  experimenting  with 
geosynchronous  relay  satellites  to  further  improve  the  uplink-image-downlink  cycle 
times.  While  a  typical  sensor  has  a  revisit  interval  of  3  to  5  days  (including  off-axis 
capability),  each  new  satellite  increases  the  opportunities  to  image  a  particular  target 
quickly,  and  a  constellation  of  three  or  more  satellites  almost  assures  access  to  any 
location  within  24  hours  in  a  typical  low-earth-orbit  remote  sensing  scenario  with  a 
mid-morning,  sun-synchronous  satellite  flyover  time. 
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Problem  Statement 


The  National  Air  and  Space  Intelligence  Center  “assesses  current  and  projected 
foreign  aerospace  capabilities  and  intentions...  and  evaluates  evolving  technologies  of 
potential  adversaries.”  (NASIC,  1996).  Determining  the  timeliness  of  commercial 
imagery  accessible  by  these  “potential  adversaries”  is  obviously  a  necessary  part  of 
assessing  their  capabilities.  The  question  is  also  relevant  to  any  friendly  party  wishing  to 
assess  a  natural  disaster,  a  man-made  disaster,  or  any  other  urgent  need  for  information. 

The  question  this  research  set  out  to  address  is,  “What  is  the  shortest  time,  in 
general,  it  takes  to  receive  an  image  of  a  general  target?”  The  question,  as  addressed, 
concerns  itself  only  with  commercial,  not  military,  imaging  satellite  systems,  and 
assumes  a  visible  light,  panchromatic  image  with  one  of  two  resolution  ranges.  While  the 
broadest  interpretation  of  the  question  does  not  address  satellite  resolution  or  a  particular 
image  type  (e.g.  Visible  panchromatic,  infrared  (IR),  IR  and  visible  multi-spectral, 
Synthetic  Aperture  Radar  (SAR),  etc.),  I  chose  to  narrow  the  scope  of  the  research  in 
order  to  limit  the  permutations  possible  with  resolution  and  image  type.  Further 
justification  is  provided  by  the  great  preponderance  of  visible  light  sensors  on 
commercial  systems  rather  than  SAR  or  infrared  (other  than  near-IR  on  many 
multispectral  capable  sensors). 

The  specification  of  a  “general”  time  to  image  a  range  of  possible  targets  is 
extremely  significant.  The  are  a  number  of  programs  available  (such  as  Analytical 
Graphics  Inc.’s  Satellite  Tool  Kit  or  the  Aerospace  Corporation’s  Satellite  Orbit  Analysis 
Program)  that  would  allow  the  user  to  designate  a  start  time,  satellite,  uplink  station, 
target,  and  downlink  station  and  determine  how  much  time  would  pass  between  start  time 
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and  downlink  opportunity.  However  this  method  presupposes  a  particular  satellite 
position  at  the  start  time  and  a  specific  target  for  the  analysis.  This  is  not  an  appropriate 
approach  to  the  general  time,  general  target,  and  general  satellite  problem. 

A  second  question,  on  the  tail  of  the  primary  question  of  time,  asks  what  aspects 
in  the  request-to-delivery  process  are  the  most  significant  to  the  total  process  duration. 
The  attempt  is  made  to  answer  this  both  in  term  of  total  time  involved  and  greatest 
contributors  to  variability  in  total  time  to  delivery.  As  the  results  will  demonstrate,  even 
this  simplification  leads  to  different  answers  under  various  conditions  and  targets. 

A  more  complete  description  of  timeliness  in  the  U.S.  military  intelligence 
process  can  be  found  in  Pawling  (2004),  whose  thesis  defense  I  attended,  and  provided 
my  introduction  to  the  use  of  Rockwell’s  Arena  environment  as  a  means  of  addressing 
the  processes  I  deal  with  in  this  research  (see  also  Miller,  2004). 

Objective 

The  objective  of  this  research  is  twofold:  First,  to  develop  an  Arena  model  of 
commercial  satellite  operations  sufficient  in  detail  to  answer  the  questions  of  timeliness 
posed  in  the  previous  paragraphs;  second,  to  make  the  model  sufficiently  flexible  to  allow 
future  exploration  of  alternate  variations  on  satellite  or  ground  architectures  for  satellite 
imagers.  In  other  words,  to  design  a  model  that  not  only  answers  the  questions  originally 
asked,  but  also  enables  discovery  of  the  next  generations  of  questions  and  their  solutions. 
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II.  Literature  Review 


Process  Descriptions 

The  processes  of  commercial  satellite  imaging  operations  are  not  usually 
discussed  outside  of  the  individual  company  channels  for  reasons  of  proprietary 
advantage  (Erikson,  2004).  While  the  company  or  satellite  user  guides  discuss  services 
offered,  they  offer  only  the  broadest  sense  of  internal  process.  Time,  the  figure  of  interest 
in  this  study,  is  addressed  in  company  literature  as  a  “promised-by”  value  for  the  purpose 
of  setting  prices  with  a  steep  premium  for  short  turn  requirements. 

The  exceptions  are  the  two  ACS  Defense  studies  (Zesiger,  2000  &  2001) 
conducted  for  NASIC  that  were  given  to  me  at  the  beginning  of  my  research.  The  reason 
for  the  company  data  included  in  those  reports  was  the  government  purpose  of  the 
research  and  the  limited  distribution  of  the  report.  Nevertheless,  without  revealing  the 
details  of  any  particular  company,  Zesiger  developed  a  generalized  process  that  the 
companies  use  to  take  in  requirements  and  eventually  return  the  customers’  images.  The 
actual  progression  of  actions  and  the  labels  of  the  intermediate  stages  may  go  by  different 
names  for  any  given  company  and  the  steps  may  be  combined  or  broken  out  more  than  in 
the  model,  but  it  serves  as  a  useful  framework  on  which  to  build  (Figure  1). 
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Figure  1.  Commercial  Satellite  Remote  Sensing  Process  (adapted  from  Zesiger,  2001) 


Zesiger  Model  Overview 

Given  the  importance  of  the  Zesiger  (2001)  generalized  model  to  this  research, 
the  following  summary  is  provided. 

1.  User  contacts  satellite  operator’s  customer  liaison  to  determine  the  following. 

a.  Target  area  and  type 

b.  Range  of  dates  for  desired  imaging 

c.  Maximum  acceptable  cloud  cover 

d.  Image  viewing  angle  limits  (and  direction) 

e.  Type  of  sensor  to  be  used  (a  company  may  have  access  to  more  than  just 
electro-optical  imagers) 

f.  Type  of  data  delivery  (mail,  courier,  FTP  data  transfer) 

g.  Level  of  processing  (see  Table  1) 

h.  Required  timeliness  (varies  by  vendor  from  2  levels  to  5) 

2.  The  liaison  forwards  the  initial  order  request  to  the  Payload  Operations  Center 
(POC)  for  analysis,  study  and  acquisition  plan  proposal. 

3.  The  liaison  contacts  the  user  with  the  POC  proposal  for  user  approval.  If  the 
proposal  is  accepted,  payment  is  arranged. 

4.  The  plan  is  forwarded  to  the  Satellite  Control  Center  (SCC)  where  it  is  tested  for 
feasibility  and  satellite  command  generation.  Note  that  the  command  includes  the 
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information  needed  by  the  satellite  to  image  the  target  and  how  to  download,  or 
store  and  download  later,  the  resulting  sensor  data. 

5.  Commands  are  forwarded  to  the  Satellite  Control  Site  (SCS)  for  uplink  when  the 
satellite  is  in  view. 

6.  The  satellite  receives  the  commands. 

7.  The  sensor  collects  the  data  and  downlinks  it  at  the  programmed  time  to  a  Data 
Reception  Site  (DRS). 

8.  The  DRS  forwards  the  data  to  a  Data  Processing  Site  (DPS)  for  processing. 

9.  Processed  data  is  sent  to  a  Data  Analysis  Element  (DAE)  if  this  was  ordered  by 
the  customer. 

10.  The  final  product  is  delivered  to  the  user  in  the  manner  agreed. 

It  is  important  to  note  that  the  Zesiger  model  was  developed  as  a  precursor  to  a  target, 
satellite  and  ground  system  specific  predictor,  thus  the  inclusion  of  options  la-h  in  the 
model.  As  previously  noted  (see  the  Problem  Statement),  it  is  not  the  intent  of  this 
research  to  fix  these  particulars.  The  process  steps  described  above  are  those  used  as  the 
first  level  of  processes  for  the  model  developed  in  this  research. 

Using  the  Zesiger  methodology,  a  user  generates  a  request  to  one  company  with 
all  the  particulars  at  a  certain  start  time,  to.  Steps  1  to  4  are  performed  by  the  satellite 
company  for  a  duration  of  time,  di,  then  the  orbit  calculator  determines  the  times  of  the 
next  uplink  opportunity  after  to+di  based  on  satellite  ephemeris,  antenna  locations  and 
limits,  minimum  duration  and  SCS  policies  (some  companies  only  command  once  daily, 
some  when  required  from  several  possible  locations  (Zesiger,  2000)).  After  uplink,  a 
period  of  time  will  pass  before  imaging  can  occur,  dimage,  followed  by  a  calculation  of 
downlink  opportunity  similar  to  the  uplink  calculation.  Steps  7  through  9  take  various 
amounts  of  time  based  on  company  resources  and  the  particular  processing  and  analysis 
options  selected  by  the  user,  dpr0c  and  delivery  options  ddeiiver-  The  total  duration  of  the 
operation  is  then  calculated  by  adding  the  minimum  and  maximum  durations  to  the  start 
time,  as  shown  below. 


7 


min  (DurationTotal  )  =  t0+  min  (dup )  +  min  (dimage )  +  min (ddown )  +  min  (dproc )  +  mm(cldeliver ) 
ma x(DurationTotal  )  =  t0+  ma x(dup )  +  ma  x(dimage )  +  ma x(ddown )  +  ma  x(dproc )  +  ma x(ddeliver ) 

If  the  Zesiger  calculation  were  repeated  with  the  same  start  time  and  user  selections  the 
answer  range  would  be  the  same  in  each  instance.  Each  satellite  and  satellite  operator 
would  also  have  different,  but  unchanging,  answers  for  each  case,  even  if  the  satellites 
were  otherwise  identical,  based  on  orbital  position  at  to. 

Pawling  Model  Overview 

Pawling  (2004)  modeled  the  U.S.  military  intelligence  process  as  described  in 
numerous  military  publications.  The  model  assesses  time  from  determination  of  a  need, 
through  collection,  processing  and  exploitation,  analysis  and  production,  dissemination 
and  integration,  and  communications  between  each  stage.  Each  request  had  Arena 
attributes  such  as  a  “need  by  time,”  quality  required  (1  to  5),  information  source  (1  of  13) 
and  priority  (1  to  5).  These  attributes  and  others  determined  which  steps  that  requirement 
had  to  pass  through  to  be  complete.  At  any  stage  if  the  “need  by  time”  had  been 
exceeded  the  request  was  eliminated  and  counted  as  unsatisfied. 

The  high  level  of  specificity  of  Pawling’s  model  to  the  U.S.  military  and  to 
processes  beyond  the  scope  of  the  question  guiding  this  research  made  the  model  itself 
inappropriate.  On  the  other  hand,  the  use  of  Arena  to  address  the  question  of  time 
through  a  tasking  system  is  fundamental  to  the  approach  taken  here. 
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III.  Methodology 


Overview 

The  selected  approach  for  this  research  is  similar  to  the  Zesiger  (2000,  2001) 
model,  but  different  in  two  significant  ways.  First,  in  order  to  answer  the  “time-to- 
deliver”  question  for  a  non-specific  satellite,  large  numbers  of  targets  for  imaging  are 
generated  in  a  quasi-random  fashion.  Each  “Request  For  Image”  (RFI)  passes  through 
the  stages  based  on  the  Zesiger  process  beginning  with  Customer  Service.  Targets  are 
then  collected  by  the  satellites  according  to  an  approximation  of  their  shared  orbital 
characteristics  and  determined  time  over  target  and  coverage  density  within  the 
longitudinal  span  of  each  pass.  Collection  is  further  limited  by  a  constraint  representative 
of  on-board  storage  capacity  and  other  operational  limits  before  passing  through  a  series 
of  steps  for  downlinking,  processing,  and  delivery. 

Second,  I  employ  the  satellites  cooperatively  within  a  family  corresponding  to 
resolution  capability  rather  than  individually  assess  each  satellite  against  each  target. 

This  is  done  primarily  because  developing  a  model  for  each  satellite  and  company  would 
require  an  extended  period  of  time  to  gain  access  to  the  detailed,  proprietary  information 
of  each  company  with  the  final  model  and  results  limited  to  government  entities.  On  the 
positive  side,  by  treating  the  satellites  as  a  constellation  the  results  are  comparable,  but 
not  identical,  to  such  future  architectures  as  the  eight  satellite  constellation  planned  by 
ImageSat  International  (Bar-Lev,  2001).  Alternately,  one  could  posit  a  customer  who 
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determines,  before  ordering,  which  company  could  meet  his  requirement  first  and  places 
his  order  only  with  that  company. 

Arena  Simulation  Software 

Arena  is  a  visual,  drag-and-drop,  high-level  process  simulation  environment 
based  on  the  SIMIAN  simulation  language  and  developed  by  Rockwell  Software. 

Models  are  created  using  ready  made  process  blocks  with  configurable  parameters  for 
delay  or  decision  with  simple  or  complex  rules.  Process  steps  involving  queues  are 
assigned  resources  used  to  complete  the  step,  and  the  software  allows  complex 
configurations  that  support  limits  on  resources  or  the  times  they  are  available  as  well  as 
the  order  in  which  items  are  completed  (Kelton,  2004).  Values  for  duration  of  processing 
time  or  delay  can  be  generated  by  several  distributions  with  user  specified  parameters. 

All  modeling  for  this  research  was  done  in  the  Arena  environment.  Rather  than  use 
Arena’s  built  in  analysis  tools,  however,  analysis  was  performed  using  Microsoft  Excel 
spreadsheets. 

Arena  was  selected  for  its  relatively  approachable  learning  curve,  the  intuitive 
nature  of  the  models,  and  its  availability  at  AFIT.  As  a  drag-and-drop  modeler,  it  is 
relatively  easy  to  get  started  and  behavior  of  each  block  easy  to  modify  using  the 
property  interfaces.  More  complex  behavior  of  resources,  queue  priority,  and  file  input 
and  output  were  then  developed  with  the  assistance  of  the  built  in  help  and  the  use  of  the 
Kelton  (2004)  text.  When  the  model  is  built,  it  reflects  a  traditional  flowchart  structure 
easy  to  comprehend  and  explain.  Finally,  there  were  Arena  licenses  and  experience 
available  within  the  institution. 
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Assumptions  and  Justifications 

Driven  by  the  principal  question,  “What  is  the  shortest  time,  in  general,  it  takes  to 
receive  an  image  of  a  general  target?”  and  the  interests  of  the  research  sponsor  in  the 
capabilities  of  customers  with  more  resources  and  interpretation  experience  than  typical 
businesses,  several  assumptions  are  made  for  the  purpose  of  modeling  the  shortest  time  to 
deliver. 

#1.  Certain  regions  of  the  world  are  imaged  more  than  others. 

Regions  of  greater  development  and  wealth  will  have  greater  demand  for  imagery 
for  government  studies,  research  both  public  and  private,  and  business  related  purposes. 
Regions  of  international  concern,  such  as  persistent  conflict  or  unrest,  especially  when  a 
major  government  is  involved,  such  as  the  Middle  East,  will  generate  demand  for 
imagery.  While  short  term  interest  may  arise  in  a  region,  typically  for  a  natural  disaster, 
the  period  of  interest  is  generally  much  shorter  than  the  simulation  times  used  and  they 
are,  by  definition,  unpredictable  in  location,  so  are  not  modeled. 

#2.  The  high  resolution  satellites,  and  the  associated  ground  segments,  are  treated 
as  complete,  cooperative  constellations. 

As  discussed  in  the  overview  to  this  section,  attempting  to  separate  each 
company’s  resources  would  force  the  models  and  results  to  be  handled  as  proprietary. 
What  this  assumption  implies  is  that  a  user’s  request,  no  matter  the  time  of  day,  goes  to 
any  arbitrary,  open  customer  service  department  for  processing  and,  when  complete,  to 
an  open  satellite  control  center. 

At  first  glance  the  always  open  assumption  seems  too  easy:  In  fact  it  is  fairly 
realistic.  To  illustrate  let’s  take  the  example  of  Space  Imaging.  While  the  company’s 
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U.S.  control  center  is  located  in  Colorado,  it  has  several  partner  locations  around  the 
world  that  have  autonomous  commanding  and  downloading  capabilities  that  also  take  in 
customer  requests  for  imaging  in  those  regions.  So  if  a  user  in  the  U.S.  had  a  midnight 
requirement  for  an  image  of  Asia  or  the  Middle  East,  that  user  could  place  a  call,  or  visit 
the  website,  of  the  regional  partner  (who  would  be  open  for  business)  to  place  the  order. 

A  glance  at  the  downlink  sites  of  three  of  the  four  high  resolution  systems  and  the 
medium  resolution  SPOT  system  demonstrates  the  large  number  of  opportunities  for 
image  reception  by  both  groups.  Aggregating  the  sites  into  a  single  cooperative  system  is 
also  not  so  significant  because  the  companies  themselves  are  aware  of  the  imaging 
demands  of  the  regions  and  respond  (this  is  assumption  #1).  Note  the  duplication  of  sites 
in  Pacific  Asia,  Southeastern  Asia,  the  Middle  East,  Europe,  and  the  U.S.  (Figures  2  -  4). 
Having  made  the  case  for  treatment  of  the  ground  assets  into  one  system,  it  is  simple  to 
extend  the  argument  to  treat  the  satellites  as  one  system. 


Figure  2.  Space  Imaging  Receive  Sites  (Ikonos  Guide,  2004).  U.S.  Station  in  Colorado. 
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Figure  3.  ImageSat  Receive  Sites  (Bar-Lev,  2001) 


Figure  4.  SPOT  Image  Receive  Sites  (Imagery  Acquisition,  2004) 
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Figure  5.  DigitalGlobe  Receive  Sites  (Derived  from  QuickBird  Product  Guide,  2004) 


Figure  5  illustrates  an  interesting  departure  from  the  rest  by  DigitalGlobe.  By 
putting  three  sites  in  northern  locations  they  ensure  satellite  contact  on  every  pass.  This 
is  partly  a  resource  issue,  but  business  and  legal  issues  are  also  factors.  By  virtue  of  the 
U.S.  government  0.6-meter  license  that  DigitalGlobe  operates  under,  no  image  can  be 
released  with  resolution  better  than  “the  international  average  high  resolution,”  currently 
about  1.8  meter,  within  24  hours  of  the  imaging  event.  By  not  taking  the  business  route 
that  Space  Imaging  has  with  many  international,  autonomous  “Regional  Affiliates” 
DigitalGlobe  maintains  the  necessary  control  over  image  distribution  (Izard,  2005). 

Regarding  the  orbits  of  the  satellites,  it  is  partly  due  to  weather  and  partly  a 
business  decision  to  put  electro-optical  remote  sensing  satellites  in  their  chosen  orbits.  A 
visible  light  sensor  images  during  daylight,  gathering  the  reflected  sunlight  from  the 
Earth’s  surface,  but  weather  is  also  driven  by  sunlight,  and  clouds  generally  build  during 
the  course  of  a  day.  It  is  therefore  desirable  to  have  the  satellite  pass  over  a  region  in  the 
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morning.  However,  the  long  shadows  of  early  morning  are  not  desirable,  while  the  near 
absence  of  shadows  at  noon  make  interpretation  more  difficult,  so  the  difference  is  often 
cut  with  flyovers  between  0930  and  1100  hours  local  time. 

The  physics  of  gravity  governs  the  motion  of  satellites  in  their  orbits  and,  except 
in  certain  special  orbits,  satellites  will  not  continue  to  arrive  at  the  same  time  every  day. 
One  of  these  special  orbits  is  the  sun-synchronous,  and  these  orbits  are  used  universally 
by  the  commercial  remote  sensing  systems.  However  just  because  two  satellites  share  a 
local  time  of  descending  node  (LTDN),  an  orbital  mechanics  term  for  the  local,  not 
Greenwich  Mean  Time  (GMT),  time  the  satellite  passes  from  north  to  south  over  the 
equator,  does  not  mean  they  are  in  the  same  orbit  otherwise,  nor  does  it  mean  they  have 
passed  over  exactly  the  same  ground.  In  general,  a  single  satellite  in  a  typical  low  earth, 
sun-synchronous  orbit  will  have  a  revisit  interval  (a  term  meaning  the  period  of  time 
before  a  satellite  can  view  the  same  area  again)  of  1  to  5  days. 

Revisit  interval  is  tied  to  target  latitude,  satellite  altitude,  and  the  degree  to  which 
the  satellite’s  sensor  can  look  to  the  sides.  The  larger  area  of  low  latitude  earth  compared 
to  higher  latitudes  means  longer  revisit  intervals  for  equatorial  regions  versus  mid-  or 
high-latitude  regions.  Satellites  at  higher  altitudes  can  view  greater  lateral  distances  on 
earth  using  identical  sensors  than  those  closer.  Some  satellites  (see  Appendix  B)  have  a 
greater  ability  to  turn  their  sensors  to  the  side  (Wertz,  1999).  All  these  factors  determine 
how  frequently  a  given  sensor  can  view  a  particular  target. 
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Figure  8.  Sun- synchronous  Orbits  for  Medium-Resolution  Satellites 


Because  most  imaging  is  conducted  at  mid-latitudes  and  because  the  current 
satellites  are  in  non-identical,  sun-synchronous  orbits,  this  research  assumes  that  the  high 
resolution  satellite  constellation  used  for  this  study  has  a  single  imaging  opportunity 
every  day  with  a  cumulative  probability  of  capturing  any  given  image  that  is  100  percent 
by  the  fourth  day.  This  is  not  quite  the  ideal  situation  that  would  be  created  by  a  single 
entity  that  could  carefully  spread  the  satellites  to  “fill-in”  any  coverage  gaps  such  as  the 
planned  ImageSat  constellation  already  referenced.  The  process  of  determining  the 
coverage  distribution  used  in  this  study  is  described  in  Appendix  C. 

#3.  The  users  of  interest  for  this  study  require  only  minimal  image  processing. 

The  satellite  companies  offer  image  processing  services  ranging  from  none  at  all 
(raw  from  the  satellite)  all  the  way  to  complex  multispectral  analysis  of  large  areas 
consisting  of  mosaics  of  individual  multispectral  and  panchromatic  images  combined 
with  elevation  data  and  registered  to  absolute  ground  coordinates  accurate  to  a  few 
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meters.  The  available  options  are  described  by  processing  levels  as  shown  in  Table  1. 
Note  that  the  names  of  the  levels  can  vary  with  vendor  and  may  also  include  sublevels. 


Table  1.  Image  Processing  Levels  (Zesiger,  2001). 


Level 

Description 

1 

Radiometrically  corrected  images  with  no  geometric  correction  applied 
except  chip  offset  removal. 

2 

Radiometrically  corrected  images  which  are  geometrically  corrected  to 
the  accuracy  of  the  support  data. 

3 

Radiometrically  corrected  images  which  are  geometrically  corrected  to 
the  accuracy  of  ground  control  points  visible  in  the  imagery. 

4 

Radiometrically  corrected  images  which  are  orthorectified  to  correct  for 
terrain  variations  with  or  without  ground  control  points. 

5 

Digital  terrain  data  extracted  from  stereo  imagery. 

6a 

Pan-sharpened  multispectral  imagery  (with  Level  1,  2,  3,  or  4  geometric 
processing  applied). 

6b 

Band  ratio  multispectral  imagery  (with  Level  1,  2,  3,  or  4  geometric 
processing  applied). 

7 

Image  mosaics  produced  from  multiple  small  images  (with  Level  2,  3, 
or  4  geometric  processing  applied  and  Level  6a  or  6b  processing 
optionally  applied). 

For  the  purpose  of  this  research,  images  will  only  be  processed  to  level  2  for  the 
following  reasons.  First,  the  actors  of  concern  are  assumed  to  have  higher  levels  of 
processing  capability  and  image  analysis  professionals  as  required  by  their  needs.  If  the 
analysis  is  being  done  by  the  user’s  resources,  this  obviates  the  need  to  model  such 
activities  by  the  image  provider.  It  is  entirely  reasonable  that  the  non-major  world 
powers  (as  well  as  large  non-government  actors)  are  perfectly  capable  of  maintaining  the 
hardware  and  expertise  required  to  exploit  the  commercial  imagery  they  purchase.  It 
would  also  be  extremely  unreliable  to  include  a  figure  for  the  duration  of  analysis  across 
such  a  range  of  users,  purposes  and  capabilities  in  what  is  intended  to  be  an  estimate  of 
the  shortest  time  to  delivery  of  a  generic  image.  Second,  for  many  uses  of  timely 
intelligence,  it  is  sufficient  to  know  only  coarse  details:  presence  or  absence  of  troops  or 
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supplies  at  a  location;  numbers  of  troops  or  supplies;  roads  used  by  forces;  and  other  such 
basic  tactical  or  operational  level  details.  Third,  and  finally,  by  assuming  only  the  most 
basic  level  of  processing  the  model  outputs  times  of  delivery  that  are  the  quickest;  thus 
addressing  the  basic  question  of  the  research. 

This  assumption  is  a  significant  point  of  departure  between  the  Pawling  (2004) 
model  and  my  own.  This  is  a  completely  logical  difference:  Pawling  set  out  to  model  the 
U.S.  military  intelligence  cycle  including  sub-processes  for  requirement  determination, 
collection,  analysis,  exploitation,  and  dissemination  to  the  originating  user  by  the  larger 
intelligence  activity.  This  research  is  focused  on  the  use  of  commercial  capabilities  to 
meet  the  collection  requirements  of  agencies  (not  necessarily  a  national  intelligence 
organization)  with  internal,  but  wildly  disparate,  resources  to  accomplish  the  other 
aspects  of  their  “intelligence  cycles.”  Completely  parallel  arguments  to  this  one  for 
image  processing  explain  the  absence  of  the  other  stages  of  the  intelligence  cycle 
modeled  by  Pawling  (2004)  from  this  study. 

#4.  The  satellite  operators  attempt  to  predict  cloud  cover  over  the  target  before 
scheduling  the  imaging  to  take  place. 

Spot  Image,  the  operators  of  the  SPOT  constellation  of  satellites  and 
DigitalGlobe,  in  their  respective  web  pages  and  user’s  guide,  state  that  they  use  weather 
data  to  anticipate  if  prospective  targets  will  be  clear  or  clouded  prior  to  scheduling  them 
for  imaging  by  their  satellites.  Given  the  price  commanded  by  an  image,  it  seems  likely 
that  other  companies  would  make  the  attempt  to  avoid  missing  a  clear,  and  profitable, 
shot  rather  than  take  a  picture  of  clouds.  DigitalGlobe  also  has  a  policy  of  refunding 
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partial  payment  or  reshooting  images  with  more  than  20  percent  cloud  cover,  unless  the 
customer  has  specified,  and  paid  for,  a  clearer  shot  (Quickbird  Product  Guide,  2004). 

#5.  Customer  requests  are  for  point  targets,  satisfied  by  a  single  image. 

This  assumption  is  simply  a  limitation  of  the  model  as  implemented.  It  is  not 
clear  what  proportion  of  satellite  operations  are  truly  single  image  versus  those  requiring 
multiple  images.  Of  intelligence  type  requests,  certainly  mapping  operations  are  not 
single  images,  nor  tasks  where  only  approximate  locations  of  interest  are  known  and 
searching  is  required.  On  the  other  hand,  where  a  lower  time  limit  is  desired  on  the 
possibility  of  reconnaissance,  the  single  shot  assumption  is  useful. 

#6.  Only  two  levels  of  user  specified  priority  are  used. 

Actually,  each  satellite  operator  has  different  tiers  of  promised  acquisition  and 
turn-around  for  images,  ranging  from  two  to  five  (Zesiger,  2001,  and  system  user  guides). 
Essentially,  the  more  quickly  (or  the  narrower  the  imaging  window)  you  want  an  image, 
the  more  it  will  cost.  This  turns  out  not  to  be  mere  profiteering  by  the  vendor,  but  a  real 
burden  on  the  personnel  at  each  stage,  and  on  delivery  times  of  the  lower  tier  orders 
based  on  resources.  While  Arena  supports  up  to  5  levels  of  priority,  the  assumption 
reflects  the  desire  to  get  at  a  fastest  time  to  deliver  information  to  a  user  who  is  assumed 
to  have  large  resources.  This  is  also  consistent  with  assumption  #3.  Based  on  these 
arguments,  it  is  most  appropriate  to  the  problem  to  go  with  the  fewest  levels  of  priority. 

Discussion  of  Model 

With  the  assumptions  laid  out  and  explained,  the  design  of  the  model  is  more 
easily  explained.  Convenience  dictates  discussing  the  model  in  sections  and  logically 
there  are  three  major  categories  of  activity.  First  the  Request  and  Customer  Service 
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section  (outlined  in  blue  in  Figure  9),  then  the  SCC  Processing  and  Collection  section 
(outlined  in  purple),  and,  last,  the  Post-Imaging  section  (outlined  in  green).  I  will  discuss 
the  design  and  operation  of  the  model  and  those  settings  required  for  understanding,  but 
for  complete  details  of  the  settings  for  each  block  in  the  Arena  model  see  Appendix  A  of 
this  document. 


Figure  9.  The  Commercial  Satellite  Imagery  Operations  and  Processing  Model 


As  mentioned  in  the  earlier  description  of  Arena,  it  is  possible  to  select 
from  a  large  number  of  possible  distributions  for  process  times  so  it  is  worth  discussing 
the  choices  made  for  this  model.  There  are  actually  two  distributions  used:  the  triangular 
and  the  exponential.  The  triangular  distribution  is  used  here,  given  the  lack  of  real  world 
data  from  the  satellite  operators  from  which  true  distributions  could  be  developed,  as  the 
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default  choice  (Kelton,  2004,  pi 64- 165).  A  triangular  distribution  is  described  by  three 
parameters:  a  minimum,  a  most  likely  and  a  maximum  value.  It  behaves  in  most  cases 
like  a  normal  distribution  but  without  the  possibility  of  values  beyond  the  minimum  and 
maximum.  This  makes  a  lot  of  sense  for  a  managed  process  because  there  won’t  be 
values  shorter  than  the  minimum,  and  the  managers  of  the  real  process  won’t  allow  RFIs 
to  linger  longer  than  a  maximum  amount  of  time  in  a  given  stage:  Both  of  these  not- 
allowed  situations  would  occur  with  a  normal  distribution.  Keep  in  mind  that  the 
preceding  discussion  applies  a  single  process  block,  and  is  not  necessarily  true  for  the 
overall  model  behavior. 

The  second  distribution  used  (for  the  generation  of  RFIs)  is  the  exponential  and 
requires  a  little  more  explanation.  The  arrival  of  customers,  or  phone  calls,  or  any 
number  of  other  events,  in  a  given  time  period  is  generally  a  Poisson  distribution  (Sachs, 
1984).  However,  Arena’s  parameters  for  creation  of  RFIs  ( entities ,  in  general)  are  for  the 
time  between  one  arrival  and  the  next:  this  distribution  for  a  Poisson  arrival 
distribution  is  an  exponential  distribution  with  a  mean  that  is  the  inverse  of  the  mean  of 
the  Poisson  distribution  (Walpole,  1985).  More  discussion  of  these  distributions  can  be 
found  in  the  references,  and  many  other  statistics  texts. 

Request  and  Customer  Service. 

The  first  activity  in  the  model  is  to  create  Requests  for  Imagery  (RFI).  This  is 
accomplished  using  a  create  block  with  a  distribution  (with  parameters)  to  govern  the 
creation.  Two  blocks  create  priority  1  and  priority  2  RFIs  respectively.  While  the 
distribution  used  in  both  is  exponential,  the  parameters  differ  between  priority  1  and  2  as 
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well  as  differing  between  the  run  cases.  The  baseline  case  sets  the  means  to  1  every  120 
minutes  and  1  every  6  minutes  (a  1 :20  ratio)  for  priority  1  and  2  RFIs  respectively.  The 
loads  and  the  priority  1  vs.  2  ratios  are  varied  for  different  cases.  Note  that  Arena  will 
support  other  distributions  and  even  schedules  during  which  no  orders  would  be  taken; 
these  would  be  appropriate  for  modeling  a  single  operator  with  non-24hr  service  hours. 

Each  RFI  created  goes  next  to  a  Location  Submodel  (Figure  10),  which  are  both 
identical,  where  it  is  assigned  an  attribute  called  region  that  takes  integer  values  from  1  to 
8  according  to  a  discrete  distribution  built  in  order  to  create  eight  regions  on  the  globe 
(Figure  1 1)  with  ranges  of  latitude  and  longitude  assigned  in  the  next  series  of  blocks, 
named  LatLong#.  The  RFIs  are  assigned  the  region  attribute  according  to  the  weights  in 
Table  2,  then  directed  to  the  appropriate  LatLong#  assign  block  by  the  simple  logic  in  the 
decision  block  named  Region  1. 


Rules  assigning  Lat/Long  values  (to  Attributes) 
oF  actual  geographic  regions 

Assign  a  value  to  "Region"  attribute  based  on  "Region"  value 

based  on  user  defined  discrete  cumulative  distribution 


Figure  10.  The  Location  Submodel. 
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Figure  11.  Map  of  Regions  Used 
Table  2.  Regions  and  Weights. 


Region 

attribute 

Geographical 

Region 

Weight 

(%) 

West  Longitude 
(degrees) 

Latitude 

(degrees) 

1 

Europe 

25 

-10  to  305 

35  to  55 

2 

Middle  East 

20 

300  to  330 

20  to  40 

3 

Asia 

15 

215  to  300 

10  to  50 

4 

China 

5 

230  to  280 

20  to  50 

5 

U.S. 

30 

70  to  125 

25  to  50 

6 

Brazil 

3 

35  to  70 

-35  to  5 

7 

Arctic 

1.5 

0  to  360 

55  to  90 

8 

Antarctic 

1.5 

0  to  360 

-90  to  -55 

Longitude  in  degrees  West  was  used  because  it  simplified  the  collection  logic  if  it 
increased  in  the  same  direction  as  the  sun  moves  across  the  Earth.  More  regions  are 
possible  and  overlap  is  permissible  (as  with  China  and  Asia  in  the  definition  above)  they 
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just  become  unwieldy  and,  as  in  this  case,  do  not  contribute  to  answering  the  research 
question. 

The  next  decision  and  assign  blocks  ensure  the  longitude  ranges  are  within  0  to 
360.  Values  greater  than  360  could  occur  due  to  the  use  of  a  sample  range  of  305  to  370 
for  Europe.  This  was  done  to  keep  the  range  in  one  block  rather  than  two  (0-10  and  305- 
360).  These  ranges  are  only  intended  to  be  approximate.  The  exact  values  are  not 
significant  to  the  results,  though  the  total  number  of  targets  in  a  range  of  longitude  may 
matter. 

Returning  now  to  the  main  model,  the  assign  block  To_Cust_Srv  creates  two 
significant  attributes  for  each  RFI  that  will  store  the  simulation  time  at  this  point  and 
select  a  probability  of  the  target  being  imaged  1,  2,  3,  or  4  days  from  creation.  The 
To_Cust_Srv  attribute  value  will  keep  the  start  time  for  the  RFI  as  it  progresses  through 
the  model:  Like  all  the  attributes  used  in  the  model,  it  will  remain  associated  with  the 
particular  RFI  and  serve  as  a  log  of  events  and  time  for  use  in  the  analysis.  The 
Days _2 _collect  attribute  will  be  discussed  with  the  SCC  Processing  and  Collection 
section. 

An  item  of  Arena  usage  not  mentioned  before  is  that  none  of  the  create,  assign,  or 
decide  operations  performed  on  the  RFIs  have  consumed  any  simulation  time.  That  is 
about  to  change.  The  Customer _Srv  Submodel  (Figure  12)  has  six  time  consuming  steps, 
though  only  five  may  be  encountered.  The  first  is  the  process  block  named  Contact. 

This  step  represents  the  duration  of  the  initial  phone  call  by  the  customer  to  the  customer 
liaison  for  the  purpose  of  specifying  the  particulars  of  his  desired  image  request.  This  is 
equivalent  to  step  1  of  Zesiger  (2001).  Continuing  to  follow  the  Zesiger  model,  the  next 
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step  is  PayloadjOps  for  evaluation  of  the  request.  The  next  step,  Contact2,  (Zesiger  step 
3)  involves  the  liaison  calling  (or  writing)  back  to  the  customer  with  the  actual  image 
proposal  as  drafted  by  Payload  Operations.  There  are  two  conditions  dealt  with  by  the 
two  decision  blocks  here:  the  first  is  time  lost  if  the  liaison’s  attempt  at  communication 
does  not  result  in  immediate  contact  with  the  customer;  the  second  is  the  chance  that  the 
customer  will  not  approve  the  proposal  and  it  will  have  to  go  back  to  Payload  Operations 
for  development  of  another  proposal.  The  values  used  for  the  parameters  of  these 
operations  are  included  in  Appendix  A.  Note  that  these  values  remain  fixed  in  all  the 
cases  examined  in  this  study. 


Figure  12.  The  Customer _Srv  Submodel 
The  Contact  step  also  uses  an  Arena  capability  logically  called  a  resource.  A 
resource  is  considered  an  asset  that  acts  on  items  in  the  process  queue  until  the 
processing  activity  is  complete  and  the  resource  is  freed  to  process  the  next  item.  In  this 
case,  a  resource  was  defined  and  named  Customer _srv_rep,  that  there  are  ten  reps  at  all 
times  and  that  processing  an  order  requires  one  of  these.  Therefore,  ten  liaisons  could  be 
taking  or  verifying  orders  from  ten  customers  simultaneously,  additional  customers 
would  be  put  on  hold,  or  their  correspondence  remain  unread,  until  the  resource  was 
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again  available.  The  choice  of  ten  is  somewhat  arbitrary  for  our  hypothetical  cooperative 
constellation. 

The  next  two  steps  are  fairly  simple.  The  Out_Cust_srv  block  creates  an  attribute 
for  each  RFI  that  will  store  the  simulation  time  at  this  point,  equivalent  to  the 
In_Cust_srv  entry.  The  last  step  in  this  part  of  the  model  is  a  simple  delay  (see  Appendix 
A)  that  does  not  require  a  resource,  but  captures  the  time  from  the  completion  of  liaison 
activity  and  the  first  look  at  the  new  order  by  the  SCC  Processing  personnel.  This  could 
include  transmission  time  if  the  SCC  was  not  co-located  with  Payload  Operation  or  the 
liaison  activity.  In  the  results,  the  contribution  of  this  block  will  be  counted  against  SCC 
processing  time. 

SCC  Processing  and  Collection. 

The  next  major  section  of  the  model  has  more  complex  logic  to  simulate  the 
actions  of  both  the  ground  processing  decisions  of  the  SCC  operations  and  the  collectable 
targets  from  the  orbiting  satellite.  The  process  used  here  to  simulate  the  results  of  SCC 
processing  and  satellite  collection  does  not  reflect  the  actual  processes  of  SCC  operation. 
In  truth,  the  SCC  would  take  a  requirement  and  put  it  on  something  more  like  a  calendar. 
If  a  user  wanted  an  image  of  Tokyo,  the  SCC  would  put  that  request  in  a  stack  of  requests 
that  are  obtainable  by  satellite  #1  on  pass  #14  two  days  hence.  When  it  was  time  to  work 
that  pass,  the  SCC  would  look  at  all  the  orders  for  that  pass,  try  to  satisfy  the  priority  1 
requests  then  fill  in  the  priority  2  requests  while  doing  weather  prediction  for  each 
potential  target  (see  assumption  #4).  All  that  while  ensuring  the  satellite  on-board 
memory  is  not  exceeded  between  downlink  opportunities  and  that  a  target  to  the  west  of 
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nadir  followed  by  one  to  the  east  of  nadir  are  not  too  close  to  allow  the  satellite  to  slew  in 
time  to  take  both. 

Rather  than  try  to  mirror  the  actual  chain  of  events  in  Arena,  which  would  require 
many  more  variables  and  structures  for  every  pass  (up  to  15  per  day)  for  several  days, 
what  the  earlier  assignments  of  Days_2_collect  accomplished  is  to  associate  when  each 
RFI’s  target  is  collectable  with  each  RFI  based  on  a  strictly  empirical  calculation  based 
on  coverage  analysis  like  those  in  Figure  7  for  a  latitude  of  about  36  degrees  North  (see 
Appendix  C).  The  implemented  collection  process  then  makes  a  series  of  relatively 
simple  decisions  that  determine  if  the  target  is  potentially  collectable  based  on  the 
probability  of  coverage  from  Days_2_collect ;  current  simulation  time  relative  to  the 
target  longitude;  probability  of  clear  weather  over  the  target;  and  finally,  if  there  is  room 
in  the  pass  schedule  for  another  image. 

The  first  block,  Build  SCC  Schedule  1  assigns  a  delay  to  the  process  to  imitate  the 
initial  analysis  time  to  properly  align  the  RFI  to  a  particular  pass  and  rebuild  the  stack 
according  to  priority,  weather,  satellite  memory,  and  other  factors.  This  delay  is  drawn 
from  a  triangular  distribution  with  minimum,  most  likely,  and  maximum  of  Vi  hour,  3 
hours,  and  6  hours,  respectively. 

The  Collect  Info  1  submodel  is  just  a  place  to  collect  information  about  the 
numbers  of  priority  1  and  2  requests  and  what  regions  they  fall  in.  It  is  mirrored  by  the 
Collect  Info  2  submodel  at  the  end  of  the  collection  process  in  order  to  gather  data  on 
relative  collection  times  among  the  categories  of  request  and  target  region.  The  full 
details  of  these  submodels  are  included  in  Appendix  A. 
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Figure  13.  SCC  Processing  and  Collection  Section 
The  Restack  Schedule  process  block  is  in  place  to  keep  priority  1  requirements 
first  in  the  evaluation  process  and  to  slow  the  decision  process  so  that  rejected  images 
aren’t  evaluated  again  right  away.  Likewise  the  process  blocks  named 
Hold_to_next _pass,  Hold_to_next __pass_Low,  and  Hold  12  Hours,  ensure  that  images 
rejected  for  longitude,  weather,  or  because  the  satellite  image  limit  for  the  pass  is 
exceeded,  isn’t  approved  a  few  minutes  later  as  an  independent  draw  from  the 
distribution.  In  the  weather  and  full  pass  queue  negative  situations,  the  RFI  is  held  for  12 
hours,  enough  to  miss  the  current  daylight  pass  opportunity,  but  not  enough  to  prevent  a 
try  on  the  next  opportunity  24  hours  later. 

The  six  decision  blocks  that  are  next  are  the  heart  of  the  collection  determination 
process  that  prove  to  be  the  single  largest  source  of  delay  and  variability  for  process 
times.  The  first  determines  if  the  RFI  is  polar,  for  which  regions  the  coverage  situation  is 
based  solely  on  opportunity  because  coverage  density  is  all  but  total  above  55  degrees. 
The  second,  more  likely  situation,  incorporates  two  decisions  based  on  the  empirical 
Days_2_image  cumulative  coverage  distribution  (see  Appendix  C)  and  the  current 
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simulation  time  relative  to  the  longitude  of  the  targets  relative  to  the  approximate 
positions  of  the  satellites. 

The  calculation  of  satellite  position  is  based  on  the  orbits  of  the  four  high 
resolution  imagers  (which  is  also  very  similar  for  the  medium  resolution  imagers)  and 
their  sun-synchronous  nature.  Refer  back  to  Figure  6  and  note  that  the  satellites  are  an 
angle  ahead  of  the  overhead  sun  determined  by  their  LTDNs:  For  Ikonos  2,  Orbview  3, 
and  QuickBird  2,  the  LTDN  is  1030.  Therefore  these  satellites,  when  they  cross  the 
equator,  are  1.5  hours,  or  22.5  degrees  longitude  (15  degrees  longitude  per  hour)  ahead  of 
the  noon  sun.  Keeping  in  mind  we  are  approximating  for  a  time-to-deliver  problem 
rather  than  a  rigorous  orbital  solution,  we  can  use  the  simulation  time  ( TNOW  in  Arena) 
as  GMT,  which  at  zero  corresponds  to  midnight— opposite  the  sun.  So  at  time  0000,  the 
satellites  are  13.5  hours  (202.5  degrees)  ahead  of  GMT,  and  they  will  always  be  13.5 
hours  ahead  on  their  daylight  passes  over  the  Earth.  The  corresponding  longitude  offset 
for  EROS  Al,  with  a  LTDN  of  0945,  is  14.25  hours. 

To  these  values  a  small  margin  is  added  to  account  for  the  extended  field  of  view 
of  a  satellite  at  a  nominal  altitude  of  490  km  (see  Appendix  A  for  exact  values)  and 
assuming  a  20  degree  slant  angle  (conservative  for  the  imagers  per  the  user  guides).  For 
the  mid-latitude  case,  a  margin  of  2.3  degrees  longitude  (the  calculated  margin  for  36 
degrees  latitude)  was  used  that  is  conservative  for  the  bulk  of  targets.  The  actual  values 
vary  from  1.88  at  the  equator  to  3.28  at  55  degrees  latitude  (Wertz,  1999). 

For  polar  imaging  the  field  was  widened  to  the  equivalent  of  0815  to  1200  in 
consideration  of  the  small  spacing  of  lines  of  longitude  near  the  poles.  The  margin  used 
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for  the  polar  case  is  3.76,  the  value  for  60  degrees  latitude.  Given  that  the  value  goes 
rapidly  to  22  degrees  of  longitude  in  view  at  85  degrees  latitude,  this  is  very  conservative. 

For  a  constellation  of  medium  resolution  satellites  (see  Appendix  B)  the  reasoning 
as  explained  here  would  be  the  same.  The  span  of  possible  collection  for  medium 
imagers  is  identical  to  that  of  the  high.  Where  the  high  resolution  satellites  span  LTDNs 
of  0945  to  1030,  the  medium  resolution  range  is  1015  to  1 100;  45  minutes  for  both.  The 
only  difference  between  the  two  constellations  is  the  coverage  distribution. 

The  next  decisions  are  weather  and  capacity.  The  general  approximation  for 
cloud  cover  is  that  67  percent  (ISCCP,  2005)  of  the  world  is  cloudy  at  any  given  moment 
with  seasonal,  diurnal,  latitudinal,  and  other  variations.  If  the  weather  prediction  is  poor, 
the  Days _to _collect  attribute  is  reset  with  another  draw  from  the  coverage  distribution. 
The  reason  for  resetting  the  attribute  is  that  the  satellite  coverage  does  not  repeat  every  4 
days;  each  satellite  has  its  own  cycle  interval  usually  in  the  range  of  10  to  16  days.  This 
is  the  interval  between  exact  ground  trace  repetition  and  the  value  that  would  be  used  for 
each  satellite  in  a  computation  of  single  body  coverage.  Since  the  coverage  was 
empirically  derived  over  four  day  intervals,  the  distribution  is  the  probability  that  a  target 
will  be  in  view  of  the  sensor  in  the  next  four  days.  If  an  image  is  not  taken  for  some 
reason,  it  is  appropriate  to  calculate  again  the  coverage  odds.  Finally,  capacity  is  a  limit 
on  the  number  of  images  the  imaging  constellation  can  hold  in  storage  on-board  the 
satellite  (more  on  this  in  Appendix  C). 

The  purpose  of  SCC  ops  Pri_l  is  to  hold  RFIs  until  the  pass  is  at  hand.  It  does 
this  by  assigning  a  delay  by  the  rule  1.6667  -  AMOD(TNOW,  1 .6667) ,  where  AMOD  is  an 
Arena  modulo  function  that  returns  a  real  remainder.  What  this  accomplishes  is  to  hold 
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RFIs  for  100  minutes  (1.6667  hours,  approximately  the  period  of  the  satellites)  then 
release  them  at  once  to  the  next  block  that  will  limit  their  total  number  to  100  per  pass. 

The  last  block  in  this  section  is  Collect.  This  is  a  simple  process  that  uses  four 
satellites  (as  resources)  to  shoot  targets  in  1  to  3  minutes  each.  This  is  slow  enough  that 
the  queue  can  be  emptied  during  a  single  daylight  pass,  but  not  so  fast  that  it’s  never  full 
(per  the  decision  in  the  previous  paragraphs). 

Downlink,  Image  Processing  and  Delivery. 

The  last  section  of  the  model  simulates  the  steps  the  image  goes  through  after 
collection  by  the  satellite  as  described  by  Zesiger  (2001).  Downlink  must  occur  during 
the  time  the  satellite  is  in  view  of  the  receive  station.  In  many  cases  the  downlink  occurs 
near  simultaneously  with  image  acquisition,  but  even  if  no  station  is  in  view  at  the  time 
of  imaging,  all  the  satellites  have  high  transmission  rates,  on  the  order  of  tens  of  MB/sec 
to  empty  memory  in  the  few  (generally  less  than  14)  minutes  that  the  satellite  will  remain 
in  view  of  the  receive  station.  The  next  step,  Transfer  to  Processing,  can  take  much 
longer  due  to  relatively  slow  communications  (even  a  “fast”  T1  line  is  only  1.544 
MB/sec)  that  are  available  at  some  remote  receive  stations  to  connect  to  the  processing 
centers  and  the  large  file  sizes  of  the  images.  For  example,  a  Quickbird  2  basic  pan 
image  can  be  1600MB  (Quickbird  Guide,  2004).  This  contrasts  with  Processing  itself, 
which  is  quite  fast  for  the  low  level  of  processing  assumed  for  this  study;  on  the  order  of 
one  to  five  seconds  of  computer  time  (Zesiger,  2001). 

After  basic  processing  (level  2  or  equivalent  radiometric  and  sensor  correction 
level),  the  image  can  be  examined  for  cloud  cover  in  the  image.  If  the  cloud  cover  is 
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greater  than  the  minimum  (20%  for  most  systems  per  the  company  guides)  the  scene  is 
usually  reshot,  at  which  point  the  RFI  goes  back  to  the  SCC  for  collection.  An  attribute 
set  by  the  Incr_Reshoot_Attr  process  tracks  these  RFIs. 

The  last  process  step  is  Delivery.  Similar  to  Transfer  to  Processing,  the  length  of 
time  to  complete  delivery  of  the  image  is  dependent  on  the  bandwidth  available  to  the 
company  and  the  customer.  All  the  major  companies  have  a  FTP  (File  Transfer  Protocol) 
server  for  making  images  available  to  the  customer.  For  our  well  resourced  users  (see 
assumption  #3)  this  method  of  delivery  is  used  exclusively.  In  fact,  each  company  also 
employs  physical  delivery  option  on  CD  or  digital  tape  that  lessens  the  load  on  the  FTP 
servers  and  bandwidth.  To  partially  offset  the  larger  load  in  the  model,  the  delivery  times 
for  the  very  large  images  are  relatively  fast:  a  triangular  distribution  was  used  with 
minimum  10  min  (T1  speed  with  100MB  file),  most  likely  30min  (sharing  the  T1  with  3 
users),  and  maximum  3  hours  (dial-up  modem).  The  remaining  three  blocks  serve  to 
collect  data,  write  it  to  a  file,  and  clean  up  the  Arena  entities. 

Validation 

The  process  of  commercial  imaging  operations  used  to  build  the  Arena  model  in 
this  research  was  documented  by  the  Zesiger  (2001)  study.  More  difficult  was  finding  a 
way  to  penetrate  the  proprietary  nature  of  the  industry  to  make  sure  the  demand  for 
images  was  comparable  to  the  modeled  inputs.  I  was  fortunate  enough  to  have  contact 
with  DigitalGlobe  during  the  development  of  the  model  and,  while  the  result  is  nothing 
like  what  a  constellation  of  four  Quickbird  satellites  would  look  like,  they  were  helpful  in 
providing  certain  important  load  values  (Wood,  2004  and  Izard,  2005).  In  particular,  the 
rate  of  output  was  also  deemed  of  the  expected  order. 
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Verification 


Verification  of  the  model  as  producing  accurate  delivery  times  is  not  possible  by 
virtue  of  the  assumptions  used  in  building  the  model.  By  using  an  aggregate  of  satellites 
rather  than  a  true  constellation  and  assuming  only  point  targets  rather  than  mosaic 
requests,  the  model  departs  substantially  from  existing  constellation  models  and  the  real 
collection  and  delivery  times  of  the  existing  single  satellite  operations  of  the  current 
operators. 
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IV.  Results 


Overview 

The  nature  of  the  simulation  as  a  continuously  running  model  that  is  sensitive  to 
the  number  of  RFIs  in  the  collection  process  at  any  given  time,  suggests  modeling  single 
long  runs  for  data  generation  rather  than  many  short  ones:  Essentially,  output  during  the 
period  of  time  before  the  stages  fill  to  a  steady  state  (the  ramp-up  time)  is  not  useful  for 
analysis  of  throughput  since  it  is  not  representative.  In  order  to  exclude  data  from  the 
ramp-up  period,  the  time  series  of  the  three  main  stages  of  the  model  and  their  total  were 
examined  for  the  period  of  time  at  which  they  seemed  to  stabilize. 

As  you  can  see  in  Figure  14,  the  total  duration  of  orders  stabilize  after  a  few 
hundred  hours  (the  coordinate  axis  is  labeled  in  number  of  RFIs;  the  4,126th  RFI  exited  at 
500  hours).  The  Collection  portion  of  the  program  was,  by  far,  the  driving  factor  of  total 
time:  Customer  service  and  processing  times  were  fairly  flat,  quite  small  compared  to 
collection,  and  quickly  stabilized.  The  actual  figure  selected  to  exclude  ramp-up  time 
was  500  hours,  in  favor  of  caution,  and  verified  for  each  separate  case.  A  total  of  2,500 
hours  of  simulation  time  was  run  for  2,000  hours  of  data  to  be  used  in  all  future  analysis. 
This  consistently  resulted  in  approximately  twenty  thousand  RFIs  completed  through  the 
entire  system,  a  rate  of  10.3  images  per  hour  or  247  per  day. 

Arena  could  generate  this  much  data  for  the  model  in  under  2  minutes,  if  “batch 
mode”  was  selected.  Simulations  using  the  animated  graphics  feature,  while  handy  for 
troubleshooting  and  flow  checking,  would  take  over  24  hours  to  generate  the  same  2,500 
simulated  time.  The  2,000  hours  generated  20,403  completed  images  for  the  baseline 
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case  and,  during  analysis  with  Microsoft  Excel,  was  responsible  for  generating 
unrecoverable  memory  errors  on  a  computer  with  1GB  of  RAM,  forcing  some  time- 
consuming  workarounds  and  data  sets  no  larger  than  2,000  hours.  Figures  were  also 
generated  with  the  Excel  program. 
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Figure  14.  Baseline  Time  to  Exit  for  Completed  RFIs  (in  order  complete) 

The  simulation  results  are  analyzed  as  a  baseline  case  first,  then  used  as  a 
reference  for  several  alternate  cases  of  simulation  with  variations  on  the  baseline  model 
parameters.  These  case  variations  consist  of  two  cases  that  explore  the  repercussions  of 
demand  for  imaging  certain  locations  more  than  others  (see  assumption  #1),  three  that 
explore  the  consequences  of  business  decisions  by  the  operator,  and  one  case  that  could 
be  the  result  of  either  the  environment  or  a  business  decision. 


Case  0:  Baseline  Model 

The  baseline  model  is  the  most  reflective  of  model  parameters  based  on 
discussion  with  DigitalGlobe  and  extrapolated  to  the  assumption  environment  described 
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previously.  As  the  baseline,  it  will  also  serve  as  the  point  of  departure  for  the  other 
exploratory  changes  and  comparisons  of  behavior.  Appendix  A  fully  documents  the 
parameters,  settings  and  other  configuration  items  of  this  version  of  the  model. 

The  time  series  in  Figure  14  is  obviously  uneven  and  warrants  some  explanation. 
First  of  all,  the  “bursty”  nature  of  the  time  data  is  exactly  what  should  be  expected  from  a 
model  that  is  simulating  satellite  access  to  ground  targets:  Opportunities  to  image  the 
target  can  only  occur  once  a  day,  at  best,  for  the  mid-latitude  targets  that  make  up  97 
percent  of  the  RFIs.  Therefore,  an  opportunity  lost  does  not  reoccur  for  another  24  hours. 
Given  the  coverage  situation  for  the  high  resolution  satellites,  there  is  a  41  percent  chance 
that  one  day  will  become  two  days  or  more.  This  is  in  addition  to  the  65  percent  chance 
of  cloudy  weather  over  your  target  (also  see  Figure  16  for  collection  times  only). 
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Figure  15.  Baseline  Histogram  of  Duration  Total 


The  consequence  of  the  uneven  time  to  exit  values  is  that  many  standard 


statistical  measures  are  not  useful.  For  example,  the  average  total  duration  is  84.1  hours, 
not  an  unreasonable  value  at  first  glance,  but  the  standard  deviation  is  59.5,  that  is  71%  of 
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the  average  and  highlights  the  discrete,  widely  spaced  events  that  make  up  the  sample.  A 
look  at  some  histograms  of  the  data  (Figures  15,  16,  and  17)  reveal  that  a  more  useful 
metric  for  this  data  will  be  the  median  (Sachs,  1984)  as  the  data  is  highly  skewed  to  the 
right  by  repeated  attempts  to  collect.  Note  that  the  confidence  interval  reported  by  the 
Excel  program  in  the  figures  assumes  a  normal  distribution;  not  accurate  for  the  skewed 
data  of  the  simulation:  Nor  is  the  mode  appropriate  for  real-valued  data. 

Regarding  the  differences  between  priority  1  and  2  RFI  times  in  the  process  (see 
Figure  17),  there  were  no  significant  differences  revealed  in  the  average  or  median 
baseline  simulation  results.  What  was  significant  was  the  much  longer  maximum  times 
priority  2  RFIs  spent  in  the  system  (Figure  18).  This  is  a  logical  result  given  the  relative 
scarcity  of  Priority  1  targets  (1  for  every  20)  and  their  placement  at  the  head  of  every 
queue  (except  the  Collect  block,  which  sorts  by  latitude-high  to  low). 
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Figure  17.  Baseline  Average  and  Median  Duration  Totals  for  Priority  1  and  2  RFIs. 
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Figure  18.  Baseline  Maxima  for  Duration  Total  by  Region. 

The  lack  of  significant  difference  in  the  medians  suggests  the  collection  model 
used  requires  higher  loads  than  in  the  baseline  conditions  to  bump  off  priority  2  targets  in 
large  numbers  or  that  the  model  does  not  operate  sufficiently  close  to  capacity  to  exercise 
more  frequently  the  prioritization  of  priority  1  targets.  Examination  of  the  animated 
baseline  run  does,  in  fact,  show  that  the  Room  in  Pass  que  limit  was  never  exceeded. 

This  potential  will  be  examined  in  Case  1  (no  weather  prediction)  as  65  percent  more 
RFIs  will  reach  the  queue  without  a  weather  decision,  and  in  Case  4  with  higher  rates  of 
RFIs. 


|  □  Pri  1  ■  Fri  2 


ft 

i 

A 

ll  1  i . 

The  fact  that  the  model  does  not  run  close  to  its  capacity  is  a  positive.  Given  the 
essential  question  of  the  research  to  find  shortest  times,  running  the  model  close  to  its 
maximum  throughput  would  be  counterproductive.  Of  course,  we  are  not  only  interested 
in  shortest  possible  times,  but  also  shortest  general  time.  The  result  above  indicate  that 
median  is  a  better  single  descriptor  of  general  expected  time  (60  to  70  hours)  than 
average  for  this  data,  but  the  maxima  may  be  best  for  observing  certain  effects. 
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Region  6,  7,  and  8  data  were  the  only  sets  subject  to  any  significant  variability 
(especially  priority  1)  between  runs  with  identical  parameters,  due  to  their  smaller  sample 
sizes  of  3  percent  for  region  6  and  half  that  for  regions  7  and  8.  Given  the  additional 
investment  required  to  combine  data  from  runs,  it  was  decided  not  to  pursue  better 
characterization.  This  decision  was  further  justified  by  the  absence  of  actual 
environmental  factors  in  the  model  that  make  the  model  itself  unreasonably  optimistic 
about  imaging  the  poles.  These  factors  include  the  assumption  that  imaging  occurs 
around  times  of  equinox,  providing  daylight  to  both  poles  and  the  assumption  that  polar 
cloud  cover  is  about  the  same  as  the  worldwide  average  rather  than  much  higher,  as  is  the 
case  in  truth  (ISCCP,  2005).  Finally,  the  interest  of  the  research  question  is 
fundamentally  for  non-polar  latitudes. 

Other  steps  in  the  Baseline  process  are  customer  service  and  post-collection 
processing  (Figure  19  and  20).  Both  of  these  times  are  very  small  compared  to  the 
duration  of  time  spent  in  collection,  but  for  the  very  fastest  total  times,  these  small 
periods  may  still  be  significant.  The  impact  of  processing  resources  will  also  be  explored 
in  Cases  3  and  4. 
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Figure  19.  Baseline  Duration  of  Customer  Service  Activity 


Bin 

Frequency 

0 

0 

1 

1868 

2 

10955 

3 

6389 

4 

1410 

5 

31 

6 

0 

7 

0 

8 

0 

9 

0 

ire 

Duration  Processing 


Columnl 

Mean 

1 .849873627 

Standard  Error 

0.004796637 

Median 

1.752207 

Mode 

1.317109 

Standard  Deviation 

0.689332015 

Sample  Variance 

0.475178626 

Kurtosis 

-0.348772728 

Skewness 

0.523040801 

Range 

4.134015 

Minimum 

0.40822 

Maximum 

4.542235 

Sum 

38205.44001 

Count 

20653 

Large  st  (5000) 

2.341029 

Smallest  (5000) 

1 .292697 

Confidence  Level(95.0%) 

0.009401789 

Figure  20.  Baseline  Duration  of  Post-collection  Processing 


Case  1:  No  Attempt  to  Predict  Weather  Over  Target 

In  this  case  the  PredictGoodWx  decision  in  the  SCC  Processing  and  Satellite 
Collection  section  of  the  model  is  set  to  100  percent.  Thus,  all  collectable  targets  will 
make  it  to  the  Room  in  pass  que  decision.  All  targets  in  the  Collect  process  will  be 
processed,  then  downlinked,  then  computer  processed  to  level  2  before  being  evaluated 
for  quality.  At  this  stage  the  value  for  the  Image  OK  decision,  in  the  last  section  of  the 
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model,  was  changed  to  35  percent  in  order  to  reject  the  65  percent  of  images  that  were 
taken  of  clouds.  All  of  these  failed  RFIs  must  then  be  sent  back  through  collection  for  re¬ 
imaging. 

Obviously  there  is  a  large  price  the  operator  must  pay  for  effectively  having  to 
take  65  percent  of  images  more  than  once.  This  penalty  shows  in  the  effective  number  of 
images  per  hour  for  this  case:  9.77  per  hour;  13  fewer  per  day;  1060  fewer  for  the  2000 
hours  sampled.  In  addition,  Figure  21  shows  the  costs  in  ability  to  deliver  timely  images 
to  customers  by  the  large  number  of  RFIs  above  836  hours  (34.8  days),  the  limit  of  the 
histogram. 
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Figure  21.  CASE  1  Histogram  of  Duration  Collection 
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Figure  22.  CASE  1 :  Average  and  Median  Duration  Total 
In  spite  of  the  expectation  of  extreme  behavior  in  the  2000  hours,  the  average  and 
median  values  (Figure  22)  for  total  time  in  the  system  are  not  appreciably  different  from 
the  baseline  case:  Another  view  of  the  data  is  in  order.  Looking  at  the  time  series  in 
Figure  23  (items  appear  in  the  order  they  exit  the  system),  it  is  apparent  that  the  process  is 
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exhibiting  signs  of  runaway  behavior:  Extreme  times  are  becoming  more  extreme  and 
this  also  shows  up  in  the  maximum  values  (Figure  24). 
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Figure  24.  CASE  1:  Maximum  Duration  Totals  by  Region 
The  companies  that  are  involved  in  commercial  imagery  are  aware  of  the  weather 
problem.  The  first,  and  earliest  available,  solution  was  to  have  extra  capacity  to  deal  with 
weather,  as  well  as  surge  demand.  More  recently,  weather  forecasting  has  become  a 
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business  driven  requirement  for  the  industry.  Both  QuickBird  and  SPOT  user  guides 
(2004)  highlight  the  fact  that  weather  forecasting  is  done  to  help  the  customer  get  a 
usable  image,  but  it  also  serves  a  purpose  in  SCC  pass  planning,  and  it  is  reasonable  to 
assume  other  operators  are  doing  the  same. 

The  lack  of  impact  on  average  or  median  times  in  Case  1  further  makes  the  case 
that  the  model  is  capable  of  very  high  throughput.  The  total  images  per  hour  for  Case  1, 
while  lower  than  baseline,  was  still  high  enough  that  lots  of  images  were  being 
completed,  but  it  would  be  much  more  difficult  for  the  operator  to  assure  a  given  image 
would  be  complete  in  a  short  period,  a  necessity  for  priority  1  customers. 

Case  2:  Greater  Overlap  of  Regions  in  Longitude 

For  this  case,  changes  were  made  to  the  assignment  of  latitude  and  longitude 
corresponding  to  the  geographic  regions  used  by  the  model.  The  changes  were  made 
with  the  purpose  of  creating  more  situations  where  a  single  imaging  pass  would  cover 
regions  with  a  more  equal  number  of  RFIs  for  each  region  (see  Figure  25).  This  is  a 
matter  of  environment  the  system  must  operate  in,  and  may  change  in  response  to  world 
events. 


46 


cr 


Long  {<le<j} 

Figure  25.  CASE  2:  Map  of  Overlapping  Regions. 

In  addition  to  changing  the  arrangement  of  the  regions,  the  frequencies  of  their 
occurrence  in  the  target  pool  was  changed  from  the  baseline  model  (see  Table  2)  to  make 
them  more  even  and  ensure  greater  conflict  for  imaging.  The  new  weights  are  listed  in 
Table  3.  The  altered  cumulative  distribution  for  the  RegionAssign  block  is  included  in 
Appendix  A. 


Table  3.  CASE  2:  Altered  Regions  and  Weights. 


Region 

attribute 

Geographical 
Region  (approx) 

Weight 

(%) 

West  Longitude 
(degrees) 

Latitude 

(degrees) 

1 

Europe 

20 

-10  to  305 

35  to  55 

2 

Middle  East 

20 

300  to  330 

20  to  40 

3 

Asia 

13 

215  to  300 

10  to  50 

4 

Indonesia  and  Australia 

12 

230  to  260 

-40  to  10 

5 

U.S. 

20 

70  to  125 

25  to  50 

6 

Central  America 

12 

70  to  125 

-10  to  25 
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7 

Arctic 

1.5 

0  to  360 

55  to  90 

8 

Antarctic 

1.5 

0  to  360 

-90  to  -55 

The  apparent  results  of  these  alterations  were  fairly  slight.  There  is  some  increase 
in  the  median  times  of  region  5  and  6  where  there  was  no  prior  overlap,  but  this  may  also 
be  due  to  the  more  equal  weights  between  the  two  locations  (Figure  26).  These  results 
further  indicate  that  there  is  excess  capacity  in  the  imaging  system. 
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Figure  26.  CASE  2:  Maxima  and  Median  Duration  Totals  by  Region 
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An  additional  observation  to  make  on  this  point  involves  two  significant  attributes 
of  the  model  itself.  First  is  the  random  assignment  of  latitude  and  longitude  to  target 
within  a  region.  Not  only  is  this  is  rarely  the  case  in  truth  (mapping  is  the  counter¬ 
example);  it  de-emphasizes  the  potential  for  conflict  between  two  targets.  For  example, 
targets  may  be  too  far  apart  (e.g.  on  opposite  sides  of  the  satellite’s  ground  track)  for  both 
to  be  imaged  even  though  both  are  individually  obtainable.  Second,  and  more  significant, 
is  the  assumption  that  the  four  satellite  constellation  can  take  100  images  every  100 
minutes  with  no  mechanism  for  prioritizing  by  region.  In  practice,  more  images  are  taken 
of  regions  that  can  afford  to  buy  them. 

Case  3:  Fewer  Post-collection  Processing  Resources 

This  case  decreases  the  computer  resources  assigned  to  Image  Processing  at  the 
data  processing  site  and  the  resources  assigned  to  image  Delivery  were  also  decreased. 
This  second  resources  are  called  bandwidth  in  the  model  and  can  be  considered  the  limit 
on  the  rate  at  which  the  bits  of  the  FTP  file  can  travel  from  the  satellite  operator  to  the 
customer.  The  parameters  (see  Appendix  A)  were  calculated  based  on  the  speed  a  100 
MB  image  can  travel  on  a  T1  line  (1.544  Mbps)  for  the  minimum  of  the  triangular 
distribution,  versus  a  44  Kbps  modem  for  the  maximum  time,  with  a  3 -way  shared  T1  for 
the  expected  value.  For  the  baseline  case,  40  of  these  resources  (10  per  vendor)  are 
available  to  each  of  the  cooperative  ground  system.  For  this  case,  both  sets  of  resources 
were  decreased  by  25  percent. 

This  situation  was  suggested  early  in  the  development  of  the  model  when 
apparently  effective  collection  parameters  were  still  generating  runaway  behavior  in  the 
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total  times.  Eventually  the  subtle  reliance  on  the  ground  systems  was  discovered. 
Essentially,  the  ground  systems  used  the  extended  periods  between  productive  passes  to 
work  off  the  backlog  generated  by  the  heavy  imaging  passes.  If  the  resources  are  not 
enough  to  get  through  the  backlog  before  the  next  wave  of  images  arrives,  the  backlog 
gets  bigger  and  bigger  with  every  day.  In  practice  it  is  the  total  bandwidth  in  and  out  of 
locations  that  will  matter,  breaking  the  capacity  into  40  pieces  is  just  modeling 
convenience.  The  issue  of  how  robustly  to  equip  the  ground  system  is  a  basic  question  of 
the  business  model:  Too  much  resource  costs  more  money  than  necessary  if  it  doesn’t 
bring  advantage;  too  little  will  bog  down  under  demand  and  not  allow  timely  products. 
This  is  seen  in  the  comparison  of  time  series  between  baseline  and  this  case  (Figure  27). 
The  increased  jaggedness  of  the  Case  3  data  (on  the  right)  is  symptomatic  of  periods  of 
overload  (though  not  continuing  overload). 

This  situation  can  occur  in  practice  when  remote  receive  stations  experience 
demand  they  are  not  resourced  to  handle.  These  remote  stations  were  connected  by 
commercial  modems  no  more  capable  than  household  56  K  models  (Zesiger,  2001). 

When  they  received  more  than  a  few  images  day  after  day,  they  would  have  to  be  skipped 
by  employing  satellite  storage  until  they  could  download  collected  image  data  to  another 
site. 
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Figure  27.  CASE  3:  Time  Series  Duration  Processing 
Also  significant  to  the  post-collection  processing  is  the  effect  it  has  on  the  total 
times  of  priority  1  and  2  RFIs.  Since  the  priority  Is  are  handled  first  in  processing  they 
suffer  no  degradation  (at  least  in  small  proportions)  in  the  last  stage.  However,  priority  2 
RFIs  end  up  staying  in  the  system  somewhat  longer  than  previously  (Figure  28). 
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Figure  28.  Baseline  vs.  CASE  3  Processing  Maxima  and  Medians 
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Case  4:  More  Priority  1  RFIs 

Case  4  increases  the  number,  and  thus  the  proportion,  of  priority  1  RFIs  in  the 
system  by  a  factor  of  2.  The  total  number  amounted  to  1171  more  data  points  over  the 
2000  hours,  or  about  1  extra  RFI  for  every  2  hours.  The  actual  counts  for  this  run  were 
938  more  priority  Is  and  67  fewer  priority  2s.  The  primary  effect  of  the  extra  priority 
RFIs  was  an  increase  in  the  priority  1  maxima  of  about  50  to  100  hours.  The  effect  on 
priority  2  total  times  is  also  apparent,  and  more  certain  given  the  much  larger  sample 
sizes  (Figure  29). 

The  point  of  this  case  is  to  emphasize  the  statement  made  in  the  assumptions 
(assumption  #6)  that  high  priority  treatment  should  be  costly  for  good  business  reasons. 
If  there  are  too  many  high  priority  RFIs  in  the  system  the  differential  is  diluted  for  all 
high  priority  customers.  At  this  load  and  processing  capacity  there  was  no  noted  effect 
on  time  required  to  process  priority  2  orders. 
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Figure  29.  CASE  4:  Duration  of  Processing  Maxima  by  Region 
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Case  5:  First-In-First-Out  Processing 

In  conversation  with  DigitalGlobe  (Wood,  2004)  it  was  noted  that  when  a 
customer  buys  priority  one  service  that  the  preferential  treatment  goes  all  the  way  to 
delivery.  By  changing  the  processing  priorities  of  the  two  resourced  processes  in  the 
post- imaging  section  of  the  model  to  First-In-First-Out  (FIFO)  it  was  with  the  intention 
of  measuring  the  difference  this  would  make  in  the  last  stage.  In  contrast,  no  difference 
was  noted  (Figure  30).  At  higher  loads  in  the  delivery  process,  this  would  inevitably 
slow  orders,  but  that  point  was  not  reached  in  this  case. 

One  very  significant  factor  that  differs  between  this  modeled  result  and  a  similar 
occurrence  in  the  industry  is  the  level  of  processing  assumed  in  model.  By  limiting 
consideration  to  level  2  processing  (see  Table  1)  in  the  quest  for  the  fastest  delivery 
answer,  the  model  forgoes  consideration  of  processing  levels  that  take  hours  of 
processing  time,  rather  than  minutes,  and  may  require  additional  imaging  as  well. 
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Baseline 

Processing  Maxima 


Case  5 

Processing  Maxima 


Processing  Medians 


Processing  Medians 


□  Pri  1  ■  Pri  2 


Figure  30.  Baseline  vs.  CASE  5  Processing  Maxima  and  Medians 


Case  6:  Uniform,  Worldwide  Target  Distribution 

Case  6  explores  the  system  operation  under  essentially  continuous  load.  There  is 
no  consideration  to  ocean  areas  versus  continental,  and,  for  the  purpose  of  analysis,  all 
the  world  between  55  degrees  latitude  North  and  South,  is  region  1.  There  is  predictably 
little  difference  between  the  resulting  duration  data  and  the  overall  averages  for  the 
baseline  case  (Figure  31).  Again  it  is  the  maxima  that  primarily  distinguish  between  the 
levels  of  priority. 

This  case  is  classified  an  environmental  condition  that  would  have  to  be  allowed 
for  if  the  satellite  operator  saw  their  niche  as  large  area  coverage.  This  is  not  the  case  for 
the  high  resolution  imagery  industry,  but  would  be  appropriate  for  certain  medium  and 
most  low  resolution  systems  and  products.  Synthetic  Aperture  Radar  (SAR)  systems 
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(RADARSAT  and  the  future  RADARSAT  2)  perform  in  a  mix  of  modes  including 
medium  and  low  resolution  operation  for  the  express  purpose  of  larger  area  terrain 
elevation  mapping  missions  as  well  as  being  in  demand  for  polar  images  of  sea  ice  that 
could  pose  hazards  to  shipping  and  fishing  vessels.  A  further  requirement  for  worldwide 
operations  is  a  worldwide  data  receive  architecture.  The  last  was  assumed  for  the 
aggregate  model  of  satellite  operations,  but  represents  a  real  problem  for  a  single  system 
operator. 


Average  Total  Durations 


■  Priority  1  ■  Priority  2 


Regiois 


Figure  31.  CASE  6:  Total  Duration  Average,  Maxima,  and  Median 


55 


Summary  of  Cases 

Looking  back  through  the  total  time  results  of  the  seven  cases  (Figure  32)  it  is 
apparent  that  only  the  decision  to  not  attempt  to  predict  weather  over  the  target  area 
significantly  impacted  the  turn  times  of  the  image  orders  (only  the  first  144  hours  is 
shown).  Region  5  was  used  for  the  comparison  in  the  figure  due  to  its  large  number  of 
RFIs  for  all  cases  and  its  involvement  in  Case  2’s  increased  region  overlap.  The  slight 
increase  in  RFIs  for  Case  4  results  is  attributed  to  the  larger  number  of  total  RFIs,  as  there 
was  no  change  in  other  parameters.  This  result  for  case  4  also  serves  to  highlight  the 
capacity  of  the  model  to  handle  more  orders  than  were  present  in  these  cases.  In  fact,  an 
attempt  was  made  to  determine  the  model’s  RFI  ceiling,  but  an  entity  limit  in  the  Arena 
software  was  reached  before  any  RFI  ceiling  was  observed. 


Duration  Total  Histogram  Comparison 


0  24  48  72  96  120  144 
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Figure  32.  Region  5  Duration  Totals  For  All  Cases 
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Another  way  of  looking  at  the  histogram  data  for  the  cases  is  shown  in  Figure  33. 
This  is  a  plot  of  the  5000th  largest  (counted  back  from  the  maximum)  and  5000th  smallest 
(counted  up  from  the  minimum)  duration  totals  for  each  of  the  Cases  and  including  all  the 
regions.  This  figure  also  demonstrates  the  tendency  of  the  total  time  data  to  skew 
rightward  in  Case  1,  as  weather  forces  reshooting  images,  and  in  Case  2,  which  was  not 
previously  noted,  as  a  consequence  of  greater  overlap  of  regions.  However,  the  turn  time 
of  the  fastest  5000  RFIs  is  only  slightly  impacted  in  all  the  cases. 
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Looking  at  a  case-wise  summary  (again  using  region  5)  of  the  three  basic 
statistics  used  (Figure  34),  the  same  result  is  not  as  clearly  observed  as  Case  1  did  not 
generate  large  spikes  in  maxima  for  Region  5.  In  fact,  Figure  34  highlights  the  small 
range  of  eight  hours  or  less  for  the  case  averages  and  medians.  Note  the  y-axis  scale  is 
different  for  figure  34  than  previous  graphs  for  the  individual  cases. 
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Figure  33.  5000th  Largest  and  Smallest  Duration  Totals 
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Figure  34.  Region  5  Average,  Median,  and  Maxima  for  All  Cases 
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V.  Conclusions 


Summary 

The  basic  question  this  research  set  out  to  answer  was  to  estimate  the  shortest 
time,  in  general,  it  takes  to  receive  an  image  of  a  general  target.  The  most  general  answer 
is  a  median  of  60  to  70  hours  if  the  baseline  assumptions  are  accurate  for  the  situation. 
Significantly,  the  5000th  lowest  sample  of  about  20,000  (1/4  of  the  orders)  was  only  41.8 
hours,  with  700  below  24  hours  (3.4%).  For  prediction  of  a  particular  image  order, 
environmental  factors  dominate.  The  single  most  important  additional  information  you 
can  have  is  an  accurate  cloud  forecast  of  the  target  location.  Weather  is  generally  even 
more  important  (67%)  than  the  satellite  coverage  (60%),  though  uncertainty  in  weather 
forecasts  will  always  be  far  greater  than  satellite  positions. 

The  model  built  to  answer  the  question  proved  robust  enough  to  explore 
variations  on  the  environment  and  the  assumptions  that  went  into  its  baseline  results,  and 
much  more  could  be  done.  Questions  of  varied  load,  computer  and  bandwidth  resources, 
weather  impacts,  and  longitudinal  demand  were  easily  altered  in  the  model  with  the 
capability  to  do  more  as  analysis  capability  allows.  The  coverage  technique  allows 
general  questions  of  access  over  time  to  be  answered  without  reliance  on  moment  to 
moment  calculations  by  dedicated  programs  with  learning  curves  every  bit  as  steep  as 
Arena. 

Limitations  of  the  model  are  its  aggregate  system  assumptions  and  lack  of  an  easy 
to  use  analysis  tool.  While  it  was  a  deliberate  move  to  examine  all  the  imaging  satellites 
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collectively,  it  would  require  changing  a  host  of  parameters  to  make  the  model  a  tool  for 
assessing  the  pluses  and  minuses  of  a  particular  system  or  system  change,  nor  would 
many  of  the  other  assumptions  hold  true  for  a  single  system.  Analysis  tools  are  essential 
for  any  simulation  model  intended  to  generate  results  in  response  to  its  users’  questions: 
without  them  a  model  may  not  be  worth  using  for  the  task.  In  retrospect,  Excel  was  not 
the  best  tool  to  answer  many  of  the  questions  that  could  be  posed  to  the  model. 


Future  Research 

There  are  three  main  directions  for  furthering  the  model.  The  first  is  the  satellite 
collection  model.  Separate  models  for  each  satellite  could  be  developed  with  specific 
orbit,  viewing  ability,  and  targeting  logic  to  better  emulate  actual  satellite  operations’ 
specific  and  limiting  factors.  These  could  operate  simultaneously  on  an  RFI  with  the  first 
to  turn  it  around  providing  the  what-is-the-fastest  answer.  If  extended  to  include  different 
ground  models  (e.g.  DigitalGlobe’s  polar  stations,  or  the  more  common  basing  in  high 
demand  areas)  the  model  could  provide  even  more  detailed  results  to  general  and  even 
particular  questions  of  coverage  or  accessibility. 

The  second  area  addresses  the  single  target  limitation.  By  not  allowing  the  model 
to  handle  multiple  images  per  order/product,  the  model  underestimates  a  great  deal  of  the 
demand  on  the  satellite’s  sensor.  According  to  DigitalGlobe  (Izard,  2005)  point  targets 
are  the  exception  to  the  usual  order.  Not  only  does  this  result  in  the  model 
underestimating  demand  on  the  sensor,  it  also  dramatically  under-represents  the  demands 
on  the  operators’  computer  processing  capabilities  and  the  personnel  who  use  them,  since 
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the  multi-shot  tasks  consume  vastly  more  of  these  resources  than  level  2  processing  of  a 
single  image. 

The  third  problem  has  already  been  discussed  somewhat;  the  problem  of  an 
analysis  tool.  While  this  model  used  a  text  file  output  for  processing,  Arena  generates  a 
richer  Access  database  output  file.  A  strong  programmer  could  build  better  visualization 
and  statistical  tools  using  either  of  these  outputs  than  used  in  this  study.  The  motivation 
to  do  so  is  in  the  promise  of  the  other  two  approaches  to  have  a  more  flexible,  realistic, 
and  powerful  tool  to  assess  imaging  space  and  ground  systems  for  responsiveness. 
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Appendix  A  -  Arena  Model  Configuration 
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signirtg  IM/Iang  values-  (la  Atfj-ib/^s.) 
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Ten  customer  liaisons 


Figure  A3.  Customer  Service  Submodel 
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Figure  A4.  Collect  Info  1  Submodel 
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Figure  A5.  Collect  Info  2  Submodel 
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Block  Name 

Type 

Parameters 

RequestPril 

Create 

Entity  Type:  RFP  1 

Time  Between  Arrivals:  Type=Random  (Expo); 

Value=2  hr 

Entities  per  Arrival=l;  Max  Arrivals=Infinite;  First 
Creation=0 

Value=l  hr  for  CASE  4 

Request_Pri_2 

Create 

Entity  Type:  RFP  2 

Time  Between  Arrivals:  Type=Random  (Expo); 
Value=0.1  hr 

Entities  per  Arrival=l;  Max  Arrivals=Infinite;  First 
Creation=0 

Location  Submodel 

1  and  2 

RegionAssign 

Assign 

Assignments:  Type= Attribute,  Name=Region, 
Value=DISC(.25,l,  .45,2,  .6,3,  .65,4,  .95,5,  .97,6, 
.985,7,  1.0,8): 

Altered  to  DISC(.2,1,  .4,2  .53,3,  .65,4,  .85,5,  .97,6, 
.985,7,  1,8)  for  CASE  2 

Altered  to  Value=l  for  CASE  6 

Region  1 

Decide 

Type=N-way  by  Condition 

Conditions:  IF  Attribute  NAMED  Region  ==  1 

IF  Attribute  NAMED  Region  ==  2 

IF  Attribute  NAMED  Region  ==  3 

IF  Attribute  NAMED  Region  ==  4 

IF  Attribute  NAMED  Region  ==  5 

IF  Attribute  NAMED  Region  ==  6 

IF  Attribute  NAMED  Region  ==  7 

IF  Attribute  NAMED  Region  ==  8 

LatLongl 

Assign 

Type=Attribute,  Name=Long,  Value=unif(305,370) 
Type= Attribute,  Name=Lat,  Value=unif(35,55) 
Type=Attribute,  Name=Pri_Region,  Value=51 

Pri  Region  attribute  not  used  in  current  analysis 
CASE  6:  Long=unif(0,360),  Lat=unif(-55,55) 

LatLong2 

Assign 

Type=Attribute,  Name=Long,  Value=unif(300,330) 
Type=Attribute,  Name=Lat,  Value=unif(20,40) 
Type=Attribute,  Name=Pri_Region,  Value=52 

Pri  Region  attribute  not  used  in  current  analysis 

LatLong3 

Assign 

Type= Attribute,  Name=Long,  Value=unif(2 15,300) 
Type=Attribute,  Name=Lat,  Value=unif(  10,50) 
Type=Attribute,  Name=Pri_Region,  Value=53 

Pri_Region  attribute  not  used  in  current  analysis 
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Block  Name 

Type 

Parameters 

LatLong4 

Assign 

Type= Attribute,  Name=Long,  Value=unif(230,280) 
Type=Attribute,  Name=Lat,  Value=unif(20,50) 
Type=Attribute,  Name=Pri_Region,  Value=54 

Pri_Region  attribute  not  used  in  current  analysis 
Altered  for  CASE  2,  see  page  46. 

LatLong5 

Assign 

Type= Attribute,  Name=Long,  Value=unif(70,125) 
Type=Attribute,  Name=Lat,  Value=unif(25,50) 
Type=Attribute,  Name=Pri_Region,  Value=55 

Pri  Region  attribute  not  used  in  current  analysis 

LatLong6 

Assign 

Type=Attribute,  Name=Long,  Value=unif(35,70) 
Type=Attribute,  Name=Lat,  Value=unif(-35,5) 
Type=Attribute,  Name=Pri_Region,  Value=56 

Pri_Region  attribute  not  used  in  current  analysis 
Altered  for  CASE  2,  see  page  46. 

LatLong7 

Assign 

Type=Attribute,  Name=Long,  Value=unif(0,360) 
Type=Attribute,  Name=Lat,  Value=unif(55,90) 
Type=Attribute,  Name=Pri_Region,  Value=57 

Pri  Region  attribute  not  used  in  current  analysis 

LatLong8 

Assign 

Type=Attribute,  Name=Long,  Value=unif(0,360) 

Type= Attribute,  Name=Lat,  Value=unif(-90,-55) 
Type=Attribute,  Name=Pri_Region,  Value=58 

Pri  Region  attribute  not  used  in  current  analysis 

Long  Greater 
Than 

360? 

Decide 

Type=2-way  by  Condition 

IF  Attribute  NAMED  Long  >360 

Fix  to  360  Long 

Assign 

Type= Attribute,  Name=Long,  Value=Long-360 

To_Cust_srv 

Assign 

Assignments:  Type= Attribute,  Name=Days  2  collect, 
Value=DISC(0.589,l,  0.786,2,  0.911,3,  1.0,4); 
Type=Attribute,  Name=Reshoot,  Value=0; 

Type= Attribute,  Name=ToCustSrv,  Value=TNOW; 
Type=Attribute,  Name=Longl5,  Value=Long/15 

Customer  Srv 
Submodel  1 

Contact 

Process 

Action:  Seize  Delay  Release,  Priority  Medium(2), 
Resources:  Cust_srv_rep,  Quantity=l 

Delay  Type=Triangular,  Hours,  Value  Added 

Min=.05;  Value=.0833,  Max=.1667 

PayloadOps 

Process 

Action:  Delay 

Delay  Type:  Triangular,  Hours,  Value  Added 

Min=.1667,  Value=l,  Max=2 

Customer_at 

_desk 

Decide 

Type=2-way  by  Chance,  Percent  True=33 
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Block  Name 

Type 

Parameters 

Contact2 

Process 

Action:  Seize  Delay  Release,  Priority  Medium(2), 
Resources:  Cust_srv_rep,  Quantity=l 

Delay  Type=Triangular,  Hours,  Value  Added 

Min=. 0333;  Value=. 05,  Max=.  1667 

Customer_calls 

back 

Process 

Action:  Delay 

Delay  Type:  Triangular,  Hours,  Value  Added 

Min=. 0833,  Value=.  75,  Max=24 

Customer 

_approves 

order 

Decide 

Type=2-way  by  Chance,  Percent  True=90 

Order_procedes 

Process 

Action:  Delay 

Delay  Type:  Triangular,  Hours,  Value  Added 

Min=.05,  Value=.0833,  Max=.1667 

Out_Cust_srv 

Assign 

Assignments: 

Type=Attribute,  Name=OutCustSrv,  Value=TNOW; 

Forward  to  SCC 

Process 

Action:  Delay 

Delay  Type:  Triangular,  Hours,  Value  Added 

Min=. 01,  Value=.  1667,  Max=l 

Build  SCC 

Schedule  1 

Process 

Action:  Seize  Delay  Release,  Priority  Medium(2), 
Resources:  SCC  Scheduler,  Quantity=l 

Delay  Type=Triangular,  Hours,  Value  Added 

Min=.5;  Value=3,  Max=6 

Collect  Info  1 
Submodel 

Reshoot? 

Decide 

Type=2-way  by  Condition 

IF  Attribute  NAMED  Reshoot  >  0.5 

Start  Collect 
Atributes  and 
Variables 

Assign 

Type= Attribute,  Name=Start_collect,  Value=TNOW 

Collection  Data 
Out 

Decide 

Type=N-way  by  Condition 

Conditions:  IF  Entity  Type  NAMED  RFP  1 

IF  Entity  Type  NAMED  RFP  2 

Count  Pril  in 

Assign 

Type=Variable,  Name=Pl_all_in_collect,  Value= 
Pl_all_in_c°llect  +  1  (Used  for  debugging  and 
animated  run) 

RegionOutl 

Decide 

Type=N-way  by  Condition 

Conditions:  IF  Attribute  NAMED  Region  ==  1 

IF  Attribute  NAMED  Region  ==  2 

IF  Attribute  NAMED  Region  ==  3 

IF  Attribute  NAMED  Region  ==  4 

IF  Attribute  NAMED  Region  ==  5 

IF  Attribute  NAMED  Region  ==  6 

IF  Attribute  NAMED  Region  ==  7 

IF  Attribute  NAMED  Region  ==  8 
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Block  Name 

Type 

Parameters 

P1R1 

Assign 

Type=Variable,  Name=Pl_Rl_in_collect,  Value= 
PIRlincollect  +  1  (Used  for  debugging  and 
animated  run) 

P1R2 

Assign 

Type=Variable,  Name=Pl_R2_in_collect,  Value= 
Pl_R2_in_collect  +  1  (Used  for  debugging  and 
animated  run) 

P1R3 

Assign 

Type=Variable,  Name=Pl_R3_in_collect,  Value= 
Pl_R3_in_collect  +  1  (Used  for  debugging  and 
animated  run) 

P1R4 

Assign 

Type=Variable,  Name=Pl_R4_in_collect,  Value= 
Pl_R4_in_collect  +  1  (Used  for  debugging  and 
animated  run) 

P1R5 

Assign 

Type=Variable,  Name=Pl_R5_in_collect,  Value= 
Pl_R5_in_collect  +  1  (Used  for  debugging  and 
animated  run) 

P1R6 

Assign 

Type=Variable,  Name=Pl_R6_in_collect,  Value= 
Pl_R6_in_collect  +  1  (Used  for  debugging  and 

animated  run) 

P1R7 

Assign 

Type=Variable,  Name=Pl_R7_in_collect,  Value= 
Pl_R7_in_collect  +  1  (Used  for  debugging  and 
animated  run) 

P1R8 

Assign 

Type=Variable,  Name=Pl_R8_in_collect,  Value= 
Pl_R8_in_collect  +  1  (Used  for  debugging  and 
animated  run) 

Count_Pri2_in 

Assign 

Type=Variable,  Name=P2_all_in_collect,  Value= 
P2_all_in_collect  +  1  (Used  for  debugging  and 
animated  run) 

RegionOut2 

Decide 

Type=N-way  by  Condition 

Conditions:  IF  Attribute  NAMED  Region  ==  1 

IF  Attribute  NAMED  Region  ==  2 

IF  Attribute  NAMED  Region  ==  3 

IF  Attribute  NAMED  Region  ==  4 

IF  Attribute  NAMED  Region  ==  5 

IF  Attribute  NAMED  Region  ==  6 

IF  Attribute  NAMED  Region  ==  7 

IF  Attribute  NAMED  Region  ==  8 

P2R1 

Assign 

Type=Variable,  Name=P2_Rl_in_collect,  Value= 
P2_Rl_in_collect  +  1  (Used  for  debugging  and 
animated  run) 

P2R2 

Assign 

Type=Variable,  Name=P2_R2_in_collect,  Value= 
P2_R2_in_collect  +  1  (Used  for  debugging  and 
animated  run) 
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P2R3 

Assign 

Type=Variable,  Name=P2_R3_in_collect,  Value= 
P2_R3_in_collect  +  1  (Used  for  debugging  and 
animated  run) 

Block  Name 

Type 

Parameters 

P2R4 

Assign 

Type=Variable,  Name=P2_R4_in_collect,  Value= 
P2_R4_in_collect  +  1  (Used  for  debugging  and 
animated  run) 

P2R5 

Assign 

Type=Variable,  Name=P2_R5_in_collect,  Value= 
P2_R5_in_collect  +  1  (Used  for  debugging  and 
animated  run) 

P2R6 

Assign 

Type=Variable,  Name=P2_R6_in_collect,  Value= 
P2_R6_in_collect  +  1  (Used  for  debugging  and 
animated  run) 

P2R7 

Assign 

Type=Variable,  Name=P2_R7_in_collect,  Value= 
P2_R7_in_collect  +  1  (Used  for  debugging  and 
animated  run) 

P2R8 

Assign 

Type=Variable,  Name=P2_R8_in_collect,  Value= 
P2_R8_in_collect  +  1  (Used  for  debugging  and 
animated  run) 

Restack  Schedule 

Process 

Action:  Seize  Delay  Release,  Priority  Medium(2), 
Resources:  Stacker,  Quantity=l 

Delay  Type=Constant,  Hours,  Value  Added, 

Value=.05 

Region  7  or  8? 

Decide 

Type=2-way  by  Condition 

IF  Attribute  NAMED  Region  =>  7 

Collect  this  pass? 
High 

Decide 

Type=2-way  by  Condition 

IF  Expression:  ((AMOD(TNOW+16,  24)  >=  Long  15) 

&&  (AMOD(TNOW=l  1 .75,  24)  <=  Longl5)) 

Hold_to_next_pass 

Process 

Action:  Delay 

Delay  Type:  Constant,  Hours,  Value  Added 

Value=.25 

Check  Days 

Decide 

Type=2-way  by  Condition 

IF  Attribute:  Days_2_collect  <  (MOD(TNOW- 
Start  collect,  96)  +1) 

Collect  this  pass? 
Low 

Decide 

Type=2-way  by  Condition 

IF  Expression:  ((AMOD(TNOW+14.403,  24)  >= 

Long  15)  &&  (AMOD(TNOW=  13.347,  24)  <= 

Long  15)) 

Hold_to_next_pass 

Low 

Process 

Action:  Delay 

Delay  Type:  Constant,  Hours,  Value  Added 

Value=.25 

Predict  Good  Wx? 

Decide 

Type=2-way  by  Chance,  Percent  True=35: 

Percent  True=100  for  CASE  1. 

RecalcDays 

Assign 

Assignments:  Type=Attribute,  Name=Days  2  collect, 
Value=DISC(0.589,l,  0.786,2,  0.911,3,  1.0,4) 
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Hold_12  Hours 

Process 

Action:  Delay 

Delay  Type:  Constant,  Hours,  Value  Added 

Value=12 

Block  Name 

Type 

Parameters 

SCC  ops  Pri  l 

Process 

Action:  Seize  Delay  Release,  High(l), 

Resources:  Priority,  Quantity=l 

Delay  Type=Constant,  Hours,  Value  Added, 

Value=l  .6667-AMOD(TNOW,  1 .6667) 

Room  in  pass  que? 

Decide 

Type=2-way  by  Condition 

IF  Expression:  NQ(Collect.Queue)  <100 

Collect 

Process 

Action:  Seize  Delay  Release,  Priority  Medium(2), 
Resources:  sensor,  Quantity=l 

Delay  Type=Triangular,  Hours,  Value  Added 

Min=. 0167;  Value=.03,  Max=.05 

Collect  Info  2 

Collecttime 

Assign 

Type=Attribute,  Name=Collect_time,  Value=TNOW 

2Collection 

Data 

Out 

Decide 

Type=N-way  by  Condition 

Conditions:  IF  Entity  Type  NAMED  RFP  l 

IF  Entity  Type  NAMED  RFP  2 

Count_Pri_  1  out 

Assign 

Type=Variable,  Name=Pl_all_out_collect,  Value= 
Pl_all_out_collect  +  1  (Used  for  debugging  and 

animated  run) 

2RegionOutl 

Decide 

Type=N-way  by  Condition 

Conditions:  IF  Attribute  NAMED  Region  ==  1 

IF  Attribute  NAMED  Region  ==  2 

IF  Attribute  NAMED  Region  ==  3 

IF  Attribute  NAMED  Region  ==  4 

IF  Attribute  NAMED  Region  ==  5 

IF  Attribute  NAMED  Region  ==  6 

IF  Attribute  NAMED  Region  ==  7 

IF  Attribute  NAMED  Region  ==  8 

oPIRl 

Assign 

Type=Variable,  Name=Pl_Rl_out_collect,  Value= 
PIRloutcollect  +  1  (Used  for  debugging  and 
animated  run) 

Type=Attribute,  Name=plrl,  Value=l 

oPl_R2 

Assign 

Type=Variable,  Name=Pl_R2_out_collect,  Value= 
Pl_R2_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

Type=Attribute,  Name=plr2,  Value=l 

oPl_R3 

Assign 

Type=Variable,  Name=Pl_R3_out_collect,  Value= 
Pl_R3_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

Type=Attribute,  Name=plr3,  Value=l 
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oPl_R4 

Assign 

Type=Variable,  Name=Pl_R4_out_collect,  Value= 
Pl_R4_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

Type=Attribute,  Name=plr4,  Value=l 

Block  Name 

Type 

Parameters 

oPl_R5 

Assign 

Type=Variable,  Name=Pl_R5_out_collect,  Value= 
Pl_R5_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

Type= Attribute,  Name=plr5,  Value=l 

0PIR6 

Assign 

Type=Variable,  Name=Pl_R6_out_collect,  Value= 
Pl_R6_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

Type=Attribute,  Name=plr6,  Value=l 

oPl_R7 

Assign 

Type=Variable,  Name=Pl_R7_out_collect,  Value= 
Pl_R7_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

Type=Attribute,  Name=plr7,  Value=l 

0PIR8 

Assign 

Type=Variable,  Name=Pl_R8_out_collect,  Value= 
Pl_R8_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

Type=Attribute,  Name=plr8,  Value=l 

Count_Pri2_out 

Assign 

Type=Variable,  Name=P2_all_out_collect,  Value= 
P2_all_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

2RegionOut2 

Decide 

Type=N-way  by  Condition 

Conditions:  IF  Attribute  NAMED  Region  ==  1 

IF  Attribute  NAMED  Region  ==  2 

IF  Attribute  NAMED  Region  ==  3 

IF  Attribute  NAMED  Region  ==  4 

IF  Attribute  NAMED  Region  ==  5 

IF  Attribute  NAMED  Region  ==  6 

IF  Attribute  NAMED  Region  ==  7 

IF  Attribute  NAMED  Region  ==  8 

oP2_Rl 

Assign 

Type=Variable,  Name=P2_Rl_out_collect,  Value= 
P2_Rl_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

Type=Attribute,  Name=p2rl,  Value=l 

oP2_R2 

Assign 

Type=Variable,  Name=P2_R2_out_collect,  Value= 
P2_R2_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

Type=Attribute,  Name=p2r2,  Value=l 

oP2_R3 

Assign 

Type=Variable,  Name=P2_R3_out_collect,  Value= 
P2_R3_out_collect  +  1  (Used  for  debugging  and 
animated  run) 
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Type= Attribute,  Name=p2r3,  Value=l 

oP2_R4 

Assign 

Type=Variable,  Name=P2_R4_out_collect,  Value= 
P2_R4_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

Type=Attribute,  Name=p2r4,  Value=l 

Block  Name 

Type 

Parameters 

oP2_R5 

Assign 

Type=Variable,  Name=P2_R5_  out  collect,  Value= 
P2_R5_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

Type= Attribute,  Name=p2r5,  Value=l 

oP2_R6 

Assign 

Type=Variable,  Name=P2_R6_out_collect,  Value= 
P2_R6_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

Type= Attribute,  Name=p2r6,  Value=l 

oP2_R7 

Assign 

Type=Variable,  Name=P2_R7_out_collect,  Value= 
P2_R7_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

Type= Attribute,  Name=p2r7,  Value=l 

oP2_R8 

Assign 

Type=Variable,  Name=P2_R8_out_collect,  Value= 
P2_R8_out_collect  +  1  (Used  for  debugging  and 
animated  run) 

Type= Attribute,  Name=p2r8,  Value=l 

In_minus_Out 
Priority  and 
Region 

Assign 

Type=Variable,  Name=Pl_all_collect_que, 
Value=(Pl_all_in_collect)  -  (Plalloutcollect); 
Type=Variable,  Name=P2_all_collect_que, 
Value=(P2_all_in_collect)  -  (P2_all_out_collect); 
Type=Variable,  Name=Pl_Rl_collect_que, 
Value=(Pl_Rl_in_collect)  -  (PIRloutcollect); 
Type=Variable,  Name=Pl_R2_collect_que, 
Value=(Pl_R2_in_collect)  -  (Pl_R2_out_collect); 
Type=Variable,  Name=Pl_R3_collect_que, 
Value=(Pl_R3_in_collect)  -  (Pl_R3_out_collect); 
Type=Variable,  Name=Pl_R4_collect_que, 
Value=(Pl_R4_in_collect)  -  (Pl_R4_out_collect); 
Type=Variable,  Name=Pl_R5_collect_que, 
Value=(Pl_R5_in_collect)  -  (Pl_R5_out_collect); 
Type=Variable,  Name=Pl_R6_collect_que, 
Value=(Pl_R6_in_collect)  -  (Pl_R6_out_collect); 
Type=Variable,  Name=Pl_R7_collect_que, 
Value=(Pl_R7_in_collect)  -  (Pl_R7_out_collect); 
Type=Variable,  Name=Pl_R8_collect_que, 
Value=(Pl_R8_in_collect)  -  (Pl_R8_out_collect); 
Type=Variable,  Name=P2  Rl  collect  que, 
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VaIue=(P2_Rl_in_collect)  -  (P2_Rl_out_collect); 
Type=Variable,  Name=P2_R2_collect_que, 
Value=(P2_R2_in_collect)  -  (P2_R2_out_collect); 
Type=Variable,  Name=P2_R3_collect_que, 
Value=(P2_R3_in_collect)  -  (P2_R3_out_collect); 
Type=Variable,  Name=P2_R4_collect_que, 
Value=(P2_R4_in_collect)  -  (P2_R4_out_collect); 
Type=Variable,  Name=P2_R5_collect_que, 
Value=(P2_R5_in_collect)  -  (P2_R5_out_collect); 
Type=Variable,  Name=P2_R6_collect_que, 
Value=(P2_R6_in_collect)  -  (P2_R6_out_collect); 
Type=Variable,  Name=P2_R7_collect_que, 
Value=(P2_R7_in_collect)  -  (P2_R7_out_collect); 
Type=Variable,  Name=P2_R8_collect_que, 
Value=(P2_R8_in_collect)  -  (P2_R8_out_collect); 
Type=Variable,  Name=Rl_collect_que, 
Value=(Pl_Rl_collect_que)  +  (P2_Rl_collect_que); 
Type=Variable,  Name=R2_collect_que, 
Value=(Pl_R2_collect_que)  +  (P2_R2_collect_que); 
Type=Variable,  Name=R3_collect_que, 
Value=(Pl_R3_collect_que)  +  (P2_R3_collect_que); 
Type=Variable,  Name=R4_collect_que, 
Value=(Pl_R4_collect_que)  +  (P2_R4_collect_que); 
Type=Variable,  Name=R5_collect_que, 
Value=(Pl_R5_collect_que)  +  (P2_R5_collect_que); 
Type=Variable,  Name=R6_collect_que, 
Value=(Pl_R6_collect_que)  +  (P2_R6_collect_que); 
Type=Variable,  Name=R7_collect_que, 
Value=(Pl_R7_collect_que)  +  (P2_R7_collect_que); 
Type=Variable,  Name=R8_collect_que, 
Value=(Pl_R8_collect_que)  +  (P2_R8_collect_que); 
Note:  All  but  attributes  p*r*  only  used  for 
troubleshooting  and  animation. 

Incr  Reshoot  Attr 

Assign 

Assignments:  Type= Attribute,  Name=Days  2  collect, 
Value=DISC(0.589,l,  0.786,2,  0.911,3,  1.0,4) 
Assignments:  Type= Attribute,  Name=Reshoot, 
Value=Reshoot  +  1 

Downlink 

Process 

Action:  Delay 

Delay  Type=Triangular,  Hours,  Value  Added 

Min=0;  Value=.25,  Max=.375 

Transfer  to 
Processing 

Process 

Action:  Delay 

Delay  Type=Triangular,  Hours,  Value  Added 

Min=.029;  Value=.125,  Max=.75 

Image  Processing 

Process 

Action:  Seize  Delay  Release,  Priority  Medium(2), 
Resources:  Computer,  Quantity=l 

75 


Delay  Type=Triangular,  Hours,  Value  Added 

Min=.033;  Value=. 05,  Max=.15 

Image  OK? 

Decide 

Type=2-way  by  Chance,  Percent  True=95 

Percent  True=35  for  CASE  1. 

Delivery 

Process 

Action:  Seize  Delay  Release,  Priority  Medium(2), 
Resources:  Bandwidth,  Quantity=l 

Delay  Type=Triangular,  Hours,  Value  Added 

Min=.1603;  Value=.48,  Max=3 

Block  Name 

Type 

Parameters 

Time  Stats 

Assign 

Assignments:  Type= Variable,  Name=Sim  time, 
Value=TNOW; 

Type=Attribute,  Name=Deliver_time,  Value=TNOW 

WriteData 

Write  to 
File 

Arena  File  Name=Shultz_l 

Assignments:  Type=Other 

Other:  IDENT,  Entity.Type,  Lat,  Long,  Region, 
Days_2_collect,  ToCustSrv,  OutCustSrv,  Start_collect, 
Collect  time,  Deliver_time,  Reshoot,  plrl,  plr2,  plr3, 
plr4,  plr5,  plr6,  plr7,  plr8,  p2r2,  p2r3,  p2r4,  p2r5, 
p2r6,  p2r7,  p2r8 

Note:  These  are  the  contents  of  the  text  output  file  in 
the  order  they  appear  here. 

Dispose  1 

Dispose 

Kills  entities 
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Other  Settings: 


Queue  -  Basic  Process 


Name 

Type 

Attribute  Name 

Image  Processing.Queue 

Lowest  Attribute  Value 

Entity.Type 

Delivery.Queue 

Lowest  Attribute  Value 

Entity.Type 

SCCopsPri  1. Queue 

Lowest  Attribute  Value 

Entity.Type 

Collect.Queue 

Highest  Attribute  Value 

Lat 

Contact.Queue 

Lowest  Attribute  Value 

Entity.Type 

Restack  Schedule. Queue 

Lowest  Attribute  Value 

Entity.Type 

Build  SCC  Schedule  1. Queue 

Lowest  Attribute  Value 

Entity.Type 

Contact2.  Queue 

Lowest  Attribute  Value 

Entity.Type 

CASE  5  Alters  Image  Processing  and 
Delivery  to  Fir st-in-Fir st-out 


Resource  -  Basic  Process 


Name 

Type 

Capacity 

Computer 

Fixed  Capacity 

20 

Bandwidth 

Fixed  Capacity 

40 

Sensor 

Fixed  Capacity 

4 

Priority 

Fixed  Capacity 

Infinite 

Custsrvrep 

Fixed  Capacity 

10 

Stacker 

Fixed  Capacity 

Infinite 

SCC  scheduler 

Fixed  Capacity 

Infinite 

CASE  3  Alters  the  following: 
Computer= 1 5 
Bandwidth=30 


Variable  -  Basic  Process 


Name 

Clear  Option 

Initial  Values 

All  variables  used 

System 

0 

File  -  Advanced  Process 


Name 

Access 

Type 

Operating 
System  File 
Name 

Structure 

End  of 
File 
Action 

Initialize 

Options 

Comment 

Shultzl 

Sequential 

File 

<Path>\CASE- 
0_Shultz05.txt 
(filename 
changed  to 
reflect  current 
Case) 

Free 

Format 

Dispose 

Hold 

No 
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Appendix  B  -  Remote  Sensing  Satellite  List  (2004) 


Satellite  Imagers  with  better  than  35  meter  resolution 


Satellite 

Owner/Operator 

Best 

Resolution 

Revisit 

freq 

Imaging 

time 

NORAD 

SatCat# 

Altitude 

(km) 

Deg 

Off 

nadir 

Alsat-1 

Algeria 

30  m 

27559 

686 

0 

EROS  A1 

ImageSat  (Int’l) 

18m  **** 

3  d 

LTDN 

0945 

26631 

480 

45 

Ikonos  2 

Space  Imaging 

Y  **** 

2.9  d 

25919 

680 

26 

IRS- ID 

ISRO 

5.8  m 

5  d 

LTDN 

1030 

24971 

IRS-P6 

ISRO 

5.8  m 

LTDN 

1030 

28051 

817 

Landsat  5 

NO  A  A 

30  m 

16  d 

LT?N  0945 

14780 

0 

Landsat  7 

NO  A  A 

15  m 

16  d 

LTDN 

1000 

25682 

705 

0 

Orbview  3 

Orbimage 

<3  d 

LTDN 

1030 

23838 

470 

45 

QuickBird 

2 

DigitalGlobe  (US) 

^Y  **** 

3.5  d 

26953 

450 

25 

Radarsat  1 

Canadian  Space 
Agency  (Canada) 

8m 

<5  d 

LTDN 

0600 

LTAN 

1800 

23710 

798 

37-48 

fine 

SAC-C 

Comision  Nacional 
de  Actividades 
Espaciales 
(Argentina) 

30  m  (only 
active  over 
SA) 

26620 

702 

SPOT  4 

SPOT  Image 

10m 

2.4  d* 

LTDN 

1030 

25260 

832 

27 

SPOT  5 

SPOT  Image 

5  m 

2.4  d* 

27421 

20 

Tsinghua- 

1 

Tsinghua 

University  (China) 

32  m 

No  data 

No  data 

26385 

Ziyuan  1 
(CBERS 1 
or  ZY-1) 

Chinese  Academy 
of  Space  Tech 
(Brazil/China) 

19  m 

3  d 

25940 

778 

Ziyuan  2  ( 
10/00) 

China 

9m? 

No  data 

No  data 

26481  or 
27550  ? 

Ziyuan  3 
(also  ZY 

IB  or 
CBERS  2 
10/03) 

Chinese  Academy 
of  Space  Tech 
(Brazil/China) 

19  m 

28057 

778 

Tansuo  1 

10m 

28220 

600 

Satellite  List  and  owner/operator  from  Aviation  Week  and  Space  Techno 
Aerospace  Source  Book 


logy,  2004 
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*  Other  information  from  operator  web  sites  and  other  various  sources 
****  Used  in  this  study. 


Alsat-1:  http://www.spaceandtech.com/digest/flash2QQ2/flash2002-Q93.shtml 
Aqua: 

EROS-A1:  http://www.imagesatintl.eom/aboutus/satellites/satellites.shtml# 

http://www.ccrs.nrcan.gc.ca/ccrs/data/satsens/eros/erostek  e.html 

EROS  System  -  Satellite  Orbit  and  Constellation  Design;  Dr 
Moshe  Bar-Lev,  Dr.  Leonid  Shcherbina,  Mr.  Vola  Levin;  22nd 
Asian  Concerence  on  Remote  Sensing,  5-9  Nov  2001. 

ERS-2:  http://earth.esa.int/rootcollection/eeo4. 10075/ERS L5.html 
IKONOS-2:  http://www.spaceimaging.com/products/imagery.htm 
IRS- ID:  http://www.nrsa.gov.in/engnrsa/satellites/satellites.html 
IRS-P3:  http://www.nrsa.gov.in/engnrsa/satellites/satellites.html 
IRS-P5/6:  http://www.isro.org/rep2002/Links/Earth%20.htm 

http://www.nrsa.gov.in/engnrsa/ebrochure/index.html 
LANDS  AT  7:  http  ://landsat.  gsfc.nasa.  gov/proi  ect/ satellite.html 
LANDS  AT  5:  http://edc.usgs.gov/guides/landsat  tm.html 
Oceansat  (IRS-P4):  http://www.nrsa.gov.in/engnrsa/satellites/irsp4.html 
Orb  view- 1/2/3:  http://www.orbimage.com/corp/orbimage  system/satellite.html 
Quickbird  2:  DigitalGlobe  Product  Guide  at 

http://www.digitalglobe.com/product/product  docs.shtml 
Radarsat  1:  http://www.rsi.ca/products/sensor/radarsat/radarsatl.asp 
SAC-C:  http://www.invap.net/space/index-e.html 
SPOT  4/5:  http://www.spotimage.fr/html/  167  224  229  .php 
Tsinghua-1: 

http://www.space.com/news/spaceagencies/microsat  china  00101 9.html 
Ziyuan  1/2/3:  http://www.spacetodav.org/China/ChinaSatellites.html 
http://www.space.com/news/china  dod  040530.html 

http://www.globalsecuritv.org/space/world/china/zy- 1  ,htm 
Tansuo  1:  http://www.  spacedaily.com/news/ china-OOzzq  .html 


NORAD  Satellite  Catalog  Number:  http://celestrak.com/NORAD/elements/ 
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Appendix  C  -  Determination  of  Coverage  Distribution 


As  discussed  in  the  main  section  of  the  research,  satellite  coverage  of  ground 
areas  by  the  four  high  resolution  satellite  sensors  is  empirically  derived  for  use  in  this 
study.  While  it  is  a  short  exercise  to  determine  coverage  for  a  single  satellite  (Wertz 
1999  discusses  single  satellite  and  constellation  coverage  methods),  this  is  not  the  case  at 
hand.  The  different  orbital  characteristics  of  the  four  satellites  make  it  impossible  to 
determine  a  single  value  for  coverage;  the  satellites  are  constantly  changing  position  with 
respect  to  each  other. 

Starting  from  an  arbitrary  day  (2  Feb  2005),  Aerospace  Corporation’s  Satellite 
Orbital  Analysis  Program  (SOAP)  using  then  current  ephemeris  data,  with  the  same 
epoch,  for  the  four  satellites  of  interest  was  configured  to  plot  ground  swaths  for  the 
sensors  per  this  study’s  assumptions.  The  first  four  days’  coverage  was  then  sampled 
from  the  eastern  edge  of  an  EROS  A1  pass  to  the  eastern  edge  of  the  next  along 
(approximately)  the  36th  parallel  of  the  U.S.  The  swath  paths  are  shown  in  Figure  Cl. 
The  complete  set  of  twelve  swaths  is  included  on  the  CD  as  a  series  of  PowerPoint  slides, 
“Swaths.ppt”  and  in  the  SOAP  file,  “ShultzHirescontourSOAP-file.orb.” 

Coverage  sampling  was  also  accomplished  for  other  periods  of  four  days  with 
disparate  results.  The  first  day’s  coverage  can  be  as  high  as  75  percent,  2nd  day  83 
percent,  and  100  percent  by  day  three,  but  coverage  for  day  one  could  be  lower  than  half 
and  completion  by  day  four  was  more  common  across  the  eight  samples. 
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Ultimately,  the  0.589,  0.786,  0.91 1,  1.0  cumulative  distribution  was  the  one  used 
for  the  Arena  model.  It  was  randomly  selected  by  the  arbitrary  choice  of  start  date;  it  was 
not  an  extreme  case  in  the  survey  across  eight  3  and  4-day  samples;  and  there  is  no 
general  solution  possible. 


Figure  Cl.  Sensor  Coverage  for  Day  1,  Days  1-2,  Days  1-3,  Days  1-4. 

(Clockwise  from  top  left) 
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Appendix  D  -  Directory  of  CD-ROM 

Baseline  model 

Arena  model  file:  CASE-0_Shultz05.doe 

Text  output  file:  CASE-0_Shultz05.txt 

Access  output  file:  CASE-0_Shultz05.mdb 

Excel  analysis  file:  CASE-0_Shultz05.xls 

Case  1:  No  Attempt  to  Predict  Weather  Over  Target 

Arena  model  file:  CASE- l_Shultz05. doe 

Text  output  file:  CASE-l_Shultz05.txt 

Access  output  file:  CASE-l_Shultz05.mdb 

Excel  analysis  file :  CASE- 1  _Shultz05  .xls 

Case  2:  Greater  Overlap  of  Regions  in  Longitude 

Arena  model  file:  CASE-2_Shultz05.doc 

Text  output  file:  CASE-2_Shultz05.txt 

Access  output  file:  CASE-2_Shultz05.mdb 

Excel  analysis  file:  CASE-2_Shultz05.xls 

Case  3:  Fewer  Post-collection  Processing  Resources 

Arena  model  file:  CASE-3_Shultz05.doe 

Text  output  file:  CASE-3_Shultz05.txt 

Access  output  file:  CASE-3_Shultz05.mdb 

Excel  analysis  file:  CASE-3_Shultz05.xls 

Case  4:  More  Priority  1  RFIs 

Arena  model  file:  CASE-4_Shultz05.doc 

Text  output  file:  CASE-4_Shultz05.txt 

Access  output  file:  CASE-4_Shultz05.mdb 

Excel  analysis  file:  CASE-4_Shultz05.xls 

Case  5:  First-In-First-Out  Processing 

Arena  model  file:  CASE-5_Shultz05.doe 

Text  output  file:  CASE-5_Shultz05.txt 

Access  output  file:  CASE-5_Shultz05.mdb 

Excel  analysis  file:  CASE-5_Shultz05.xls 

Case  6:  Uniform,  Worldwide  Target  Distribution 

Arena  model  file:  CASE-6_Shultz05.doc 

Text  output  file:  CASE-6_Shultz05.txt 

Access  output  file:  CASE-6_Shultz05.mdb 

Excel  analysis  file:  CASE-6_Shultz05.xls 

Other  Support  Files 

SOAP  constellation  file  ShultzHirescontourSOAP-file.orb 

Swath  maps  Swaths.ppt 

Thesis  document  AFIT-GSS-ENY-05-M04.pdf 
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